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INTRODUCTION 

Intel recently introduced a new set of extensions to its 
microprocessor product line. The iAPX 86/30 and 
iAPX88/30 Operating System Processors (OSPs) aug- 
ment the general-purpose instruction set of the well- 
known 8086/8088 architecture to include common, 
real-time, operating system capabilities. A single 
device, the 80130 Operating System Firmware compo- 
nent (OSF), now provides hardware support for func- 
tions previously relegated to software. 

The 80130 introduces new concepts in the areas of both 
hardware and software. At first glance, traditional 
component-level hardware designers could feel some- 
what intimidated by the esoteric concepts and un- 
familiar buzzwords encountered in the software world. 
Even the experts in conventional operating system 
(OS) design may initially find it strange that what used 
to be “soft” software routines are now cast in silicon. 

This application note is intended for readers at both 
levels. The first section reviews the development of 
processor extensions in general and operating system 
firmware in particular. Later sections should help you 
understand what a real-time operating system can do, 
how the 80130 provides these capabilities, and how to 


design system hardware and software to take advantage 
of such features. 

The note also documents a complete (albeit simple) 
system, including schematics and listings. The reader 
may wish to reconstruct this system to get started with 
OSPs. Finally, a step-by-step description of the so- 
called “configuration” process shows how physical 
system parameters are incorporated into the software 
as the software is “installed” in memory. Through- 
out the note are a number of “exercises” — questions 
relating to concepts just presented. Please take a 
few moments to think about these questions before 
reading on. 

The reader need not have worked with operating sys- 
tems previously, though such background would be 
helpful. The reader should also know something about 
microprocessor hardware — at a minimum, how the 
8086 or 8088 devices operate. For simplicity, most of the 
software examples are written in PL/M-86, so the 
reader should be familiar with PL/M-80 or some other 
block-structured language. Finally, be forewarned that 
the configuration steps make use of several ISIS utility 
programs, including EDIT, SUBMIT, ASM86, 
LINK86, and LOC86. Readers who wish to brush up on 
any of the above should consult the appropriate Intel 
reference manuals. 
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EVOLUTION OF PROCESSOR 
EXTENSIONS 

In the early days of microcomputing (circa 1974), things 
were simple. The first microprocessors comprised just 
the central processing unit of a simple computer. Sys- 
tems built up from these processors were generally 
small, dedicated-purpose device controllers — often 
replacing the random logic of an earlier design. The 
system designer had responsibility for the development 
of the hardware and all application software. 

Semiconductor technology has progressed rapidly 
since then. Devices have become more sophisticated, 
as have the applications in which they are used. System 
functions today are more complex than they used to be, 
and are demanding more in the way of both system 
hardware and software. 

To help designers cope with this complexity, semicon- 
ductor vendors are building increasingly more 
“functionality” into their standard product lines. 
Whereas the general arithmetic functions of the 8080 
and 8085 were limited to addition and subtraction of 
eight-bit unsigned (ordinal) values, for example, the 
Intel® 8088 and 8086 now add, subtract, multiply, or 
divide eight- or 16-bit, signed or unsigned variables 
— an obvious improvement. 

The evolution of floating-point arithmetic provides an- 
other example of technology growth. Initially, design- 
ers of numeric and process-control systems each 
developed the floating-point arithmetic routines they 
needed. Intel eased this task considerably in 1977 when 
it introduced a standard floating-point format and a 
floating-point arithmetic software library, FPAL-80. In 
1978, the iSBC 310 High-Speed Mathematics Unit im- 
plemented these same functions with dedicated hard- 
ware and executed them an order-of-magnitude faster. 

The 8231 A Arithmetic Processor Unit (introduced in 
1979) provided similar functionality in one chip at much 
lower cost. To accommodate the needs of today’s 
world, the Intel RealMath'^” software standard and the 
8087 numeric coprocessor perform 80-bit floating-point 
arithmetic for high-performance 8088 and 8086 
systems. 

This evolution of floating-point hardware illustrates two 
recurring themes in the microcomputer industry. First, 
there is a natural trend toward componentization: 

1. New applications reveal a need for new types of 
functionality (in this case, floating-point arithmetic). 

2. As common requirements become evident, vendors 
develop software to serve these needs. 


3. Specialized hardware is developed to support the 
established functions more simply and effectively 
than software alone. 

In time, everything ends up in silicon. 

The second theme is this: different functions should be 
implemented in different ways to fit the customer’s 
needs. “Universal” requirements — like 16-bit 
multiplication — are best incorporated into the CPU. 
Functions needed only by certain applications — like 
high-speed, extended-precision square roots — should 
be provided as optional Processor Extensions so that 
their expense is incurred only by those who need them. 
In keeping with this philosophy, Intel currently offers 
several processor extension products (see “What’s in a 
Name?”). 

What’s in a Name? 

The 80130 Operating System Firmware (OSF) device is 
only the latest member of an extremely flexible family 
of Intel microprocessors. Its siblings include the 8086 
and 8088 Central Processing Units (CPUs), the 8089 I/O 
Processor (lOP), and a floating-point math coproces- 
sor, the 8087 Numeric Processor Extension (NPX). 
These individual standard components may be mixed 
and matched in numerous ways to create combinations 
optimized for widely varying applications. 

To make it easier to discuss the most common con- 
figurations, Intel has defined an “Advanced Processor 
Series” (iAPX) numbering scheme, something akin to 
those used in the minicomputer and mainframe worlds. 
The 8086 CPU by itself, for instance, is called the iAPX 
86/10. The 8086/8087 combination is dubbed the iAPX 
86/20. An 8086/80130 pair has the name iAPX 86/30. The 
8086, 8087, and 80130 together would form an iAPX 
86/40. 

When each of these combinations uses an 8088 in lieu 
of the 8086, each of the numbers above substitutes 
“88” for the “86”. An 8088 teamed with an 80130 is 
therefore called the iAPX 88/30. Finally, adding an 8089 
to any system changes the final zero to a one. So, an 
iAPX 88/41 system would be one using the 8088/8087/ 
8089/80130 chip set. 

Real-Time Operating Systems 

Let’s turn our attention now to the subject of micro- 
computer operating system software — an area steadily 
growing in importance. The trends toward standardized 
functions with specialized implementations will be- 
come evident. 
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But first, what is an operating system? The phrase 
means different things to different people. In 20 words 
or less: An OS is a tool, a set of programs or routines 
which reduce and simplify the problem of managing 
system resources. (Well, 21, actually . . .) 

Most microcomputer programmers have encountered 
single-user diskette operating systems, Intel’s ISIS-II®, 
and CP/M® and CP/M-86® from Digital Research Incor- 
porated among them. In essence, an OS of this sort is a 
collection of run-time subroutines which perform 
device I/O operations and give application programs 
access to a disk-based file system. Along with these are 
routines to supervise the loading and execution of ap- 
plication programs. Historically, this type of OS is 
oriented toward user-interactive applications: software 
development, business computing, and the like. 

In the mainframe world, the goal of an operating system 
is to use expensive equipment as efficiently as possible. 
Batch processing systems ensure that programs waste 
as little CPU time as possible, though each monopolizes 
the CPU until it has completed. A time-sharing OS 
allots short periodic “slices” of time to each of several 
independent users, during which each has access to the 
CPU, mefnory, and other system resources. 

A step above the traditional time-sliced OS are “real- 
time, multitasking operating systems.” But what is a 
“real-time” application? (“Don’t all programs execute 
in real time?”) 

A real-time system is one in which the CPU must do 
many different things (tasks), all more-or-less simulta- 


neously. Unlike the sequential time-sharing of 
mainframe OSs, though, the tasks are prioritized. Low- 
priority tasks are preempted if any of higher priority 
have work to do. The higher-priority task then runs 
until it must wait for some external event to occur or no 
longer needs the CPU for some other reason. Thus, the 
CPU services tasks in their order of importance. 

A computer controlling factory machinery, for in- 
stance, might perform five separate tasks: 

1 . Monitor input switches to detect emergency condi- 
tions, determine intended operating mode, or update 
indicator lights showing machine status; 

2. Drive a stepper motor to position a tool; 

3. Keep track of the time of day; 

4. Send output to the console (e.g., CRT), either in 
response to explicit commands or as part of some 
other task; 

5. Read and process characters entered from a console 
keyboard. 

These tasks seem largely unrelated, though the first few 
may be more important to system operation 
than the others. Let’s consider some alternate 
ways to accomplish these functions with today’s 
microcomputers. 

Conceptually, the most straightforward approach might 
be to dedicate a separate computer to each. The pro- 
gram for each would then be quite simple: an initializa- 
tion phase followed by an endless loop performing the 
dedicated function. Algorithms for the first four tasks 
are flowcharted in Figure 2. 



Figure 2. Flowcharts for Concurrent Machine-Tool Tasks 
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What’s wrong with this approach? Ignoring cost, the 
need for multiple CPUs becomes physically unrealistic 
for more than a few tasks — 60, say, or 600. And tasks 
are rarely fully independent; note that the switches 
monitored by task 1 could affect task 2, and that tasks 4 
and 5 interact with the rest of the system in as yet 
undefined ways. So, some sort of communications 
would have to be set up between the micros. 

Exercise 1. Suppose five tasks are all interrelated. 
How many communications channels would have 
to be set up between different processors? If each 
channel requires two dedicated communication 


chips, how would the number of peripheral 
devices compare with the number of CPUs? 

In each task, the CPU spends most of its time waiting 
for time to pass or for something to happen. One CPU 
would be able to implement all five tasks if its time were 
properly divided among them. An alternate approach, 
then, might be for a single processor to attend to each 
task in turn, performing the actions called for by each. 
Figure 3 shows a flowchart for this scheme. Only one 
CPU is required and the tasks can communicate be- 
tween themselves and share physical resources like the 
console. 



HAS \ 

'Status sampling 

s. INTERVAL ^ 
.EXPIRED? 


HAS 

STEPPING INTERVAL^ 
EXPIRED? 


ONE SECOND 
. EXPIRED? ^ 


^ ARE "V 
ANY MESSAGES 
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Figure 3. Machine-Tool Tasks Implemented Via Polling Scheme 
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The problem here is the heavy interaction between 
tasks. Before it can be serviced, an important task may 
have to wait for many other less critical tasks to com- 
plete. This imposes a constraint that each task release 
the CPU as quickly as possible. Also, lumping tasks 
together obscures the boundaries between them. In- 
itialization sequences must be grouped with each other, 
rather than with the sections of code affected. Adding to 
or deleting any task may affect the others. It’s not clear 
how to structure the program such that programmers 
could cooperate on such a program. 

Moreover, the various tasks can interfere with each 
other. Suppose on a given pass through the processor 
loop, three tasks each send one new character of a 
message to the console display screen. The resulting 
output would be most interesting. 

The third, and optimal approach, would be one which 
combined the advantages of the first two approaches, 
while avoiding the pitfalls. Each function of the overall 
system could be designed, written, and tested sepa- 
rately, as in the first approach, yet all the software 
would run on a single computer system as in the 
second. Tasks could therefore communicate with each 
other easily, and share peripherals such as CRTs. This 
multitask control and communication function could be 
performed largely through software. 

The key is finding a way to properly budget CPU time 
between the various tasks. Early pioneers of complex, 
real-time, control system design found that they needed 
special routines, apart from the application tasks them- 
selves, to supervise the execution of application tasks. 
It was (at best) an inconvenience for so many engineers 
to independently define, design, document, test and 
debug software with the same general purpose. At 
worst, schedules slipped or projects were cancelled for 
the lack of reliable executive software. 

To help avoid these hazards and free up the designers to 
concentrate on more immediate goals, Intel developed 
iRMX 80, the first real-time, multitasking, executive 
operating system for microprocessors. iRMX 86 was 
introduced to the 16-bit world two years later in 1980. 

Because of the critical real-time nature of such operat- 
ing systems, they require certain hardware capabilities 
in the host system, such as special timer logic clocked at 
certain frequencies to measure the passing of time, and 
interrupt controllers to monitor assorted asynchronous 
events. Combine all this with a handful of memory 
chips to house just the OS software, and the address 
decode and control logic needed by all of the above, and 
you’ll find you need the equivalent of a single-board 
computer system just to support a multitasking 
environment. 


Until now, that is. The current trend is to integrate OS 
software and hardware functions into silicon. Intel’s 
iAPX 432 32-bit MicroMainframe™ system does this 
within the CPU. For the 16-bit world, however, Intel 
provides a separate chip, the 80130, which contains 
operating system firmware as well as timer and inter- 
rupt control functions. 

What is the 80130 OSF? It is an extremely sophisticated 
integrated circuit, fabricated using Intel’s high- 
performance HMOS technology, which contains over 
160,000 devices. In one 40-pin package (Figure 4), the 
80130 combines several timers, multiple-mode inter- 
rupt control logic, and a large control store memory 
— plus buffers, decoders and the like — to form the in- 
tegrated heart of a multitasking operating system. 
Compared with the iRMX 86 Nucleus, for example, the 
80130 replaces an 8259 A PIC, an 8253 PIT, a special 
oscillator, 16K bytes’ worth of memory, and associated 
control logic. 

The 80130 operates in conjunction with the 8086 CPU. 
Together, the two chips are called the iAPX 86/30 OSP. 
The same device may be paired just as easily with an 
8088 forming the iAPX 88/30. From here on, though, 
references to the 8086 or “host processor” apply to 
both CPUs. Due to the high speed of HMOS, the 80130 
currently runs at system clock rates up to 8 MHz with- 
out inserting any wait states. Firmware in the 80130 
supports the 35 primitive functions listed in Table 1. 
Many of these are discussed in Chapteir IV. 

SYSTEM HARDWARE DESIGN 

The 80130 supports a wide range of system architec- 
tures, from compact to quite complex. Most, however, 
have in common the functional blocks represented in 
Figure 5. After a brief review of iAPX 86/30 systems in 
general, we’ll examine 80130 requirements in greater 
detail. 

Basic Functional Blocks 

In addition to the 80130, the central processing “core” 
of a typical OSP system would include an 8088 or 8086 
operating in maximum mode, an 82843A clock 
generator, and an 8288 system controller, all connected 
according to the standard rules. More on the 80130- 
specific interconnects later. 

Address latches (e.g., 8282s or 8283s) are generally 
needed to demultiplex the processor address bus for 
standard memory devices and for memory and I/O 
device- select logic. The number (from zero to three 
octal latches) depends on the host processor, 
memories, and the addressing scheme employed. Data 
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Table 1. Operating System Primitives Supported by 80130 


Task Management 
Suspend Task 
Resume Task 
Sleep 

Create Task 
Delete Task 
Set Priority 
Get Task Tokens 

Interrupt Management 
Set Interrupt 
Signal Interrupt 
Reset Interrupt 
Enter Interrupt 
Wait Interrupt 
Exit Interrupt 
Enable 
Disable 
Get Level 

Intertask Communications and Synchronization 

Free Memory Management/System Partitioning 

Send Message 

Create Segment 

Receive Message 

Delete Segment 

Create Mailbox 

Create Job 

Delete Mailbox 


Mutual Exclusion Control 

Misc. Support 

Receive Control 

Signal Exception 

Accept Control 

Get Type 

Send Control 

Disable Deletion 

Create Region 

Enable Deletion 

Delete Region 

Set O.S. Extension 


Get Exception Handler 


Set Exception Handler 


transceivers (8286s or 8287s) may also be needed for 
increased bus buffering. 

Any complete microprocessor system must also have 
some combination of I/O peripherals and memory, col- 
lectively indicated by the box labeled “Local Re- 
sources.” As we shall see, some of the system RAM 
and ROM (or EPROM) must be reserved for OSP itself. 
Additional logic decodes the latched address lines to 
generate chip-select signals for the memory and I/O 
devices. 

This note only discusses simple, single-processor sys- 
tems. More sophisticated architectures may incor- 
porate a multimaster system bus, in addition to a local 
processor bus. This would require additional system 
controllers, address latches, and bus transceivers for 
bus isolation, and address mapping logic (not shown) to 
select between the various busses, enable the respec- 
tive transceivers, generate a System Ready signal, and 
so forth. For design information on such techniques, 
refer to application note AP-67 in ihtiAPX 86,88 User's 
Manual. 


80130 Pin Functions 

Back to the 80130. Certain pins on the 80130 (in particu- 
lar, AD 15- ADO) attach directly to the CPU. The AD 
pins are bidirectional, accepting addresses from the 
host and returning instructions or dat£^ By monitoring 
the system clock and status signals, S2-S0, the 80130 
can decode the processor status internally and res pond 
automatically to the appropriate bus cycles. The BHE 
input lets the 80130 determine the width of data trans- 
fers and distinguishes an 8088 host from an 8086. If you 
refer back to Figure 1 , you’ll notice that these 80130 pin 
assignments were selected to simplify PC. board 
layout. 

Because of the 80130’s location on the CPU side of any 
latches or data transceivers (on what is sometimes 
called the “pin bus”), the transceivers (if used) must be 
disabled when the 80130 is driving the processor bus. 
Whenever the 80130 is re sponding to any type of bus 
cycle, it generates an ACK signal. As Figure 4 suggests, 
one way to avoid conte ntion is to sim ply disable the 
transceivers when ACK is active. ACK can also be used 
to prevent the insertion of wait states. 
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Figure 4. 80130 Internal Block Diagram 


Additional pins on the 80130 include eight interrupt- 
request inputs. Internal interrupt control logic provides 
many of the functions of the 8259A. During system 
configuration (Chapter V), each of the eight may be 
individually defined as a direct level-sensitive or edge- 
triggered interrupt request, or each may be cascaded 
with a standard 8259A in slave mode. 

The INT output must be connected to the host CPU to 
inform it of an enabled interrupt request. In very large 
systems with multiple, cas caded interrupt controllers, 
Local Interrupt Request (LIR) indicates to the bus 
contention logic whether a requesting slave is local, or 
must be accessed via a multimaster bus. 

The 80130 also contains dedicated timer logic to provide 
the OS time base, which is output on SYSTICK. 
Software operating in conjunction with the 81030 as- 
sumes one of the interrupt inputs (INT2 in this case) is 


driven by SYSTICK, so this connection must be made 
externally. Routines within the 80130 initialize and per- 
form all bit-level control of the interrupt and timer 
logic, according to options and parameters specified 
during the configuration process. Freeing the program- 
mers from this tedium allows them to devote more 
thought to solving their own unique problems. 

An additional, independent timer generates a user- 
programmable, square-wave output signal called 
BAUD to clock an off-chip US ART. 

Since the 80130 displays some of the charac?teristics of 
both memory and I/ O, it requ ires chip-s elect s ignals for 
both the memory (MEMCS) and I/O (IOCS) address 
spaces. These are discussed at length belpw. Finally, 
Intel has reserved one output pin (called “DELAY”) 
for use in future designs. Leave it unconnected in iAPX 
86/30 systems. 
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Additional System Requirements 

The OSP requires a certain amount of off-chip memory 
for its own operation. The system must provide at least 
IK bytes of RAM at address OOOOOH for the CPU 
interrupt vectors, plus another 1500io bytes for OSP 
system variables, data structures, stacks, and the like. 
This RAM may reside anywhere in the 8086 megabyte 
address space, although it is often contiguous with the 
interrupt vector up front. Application tasks must each 
have their own stack, so allow at least an additional 300 
bytes of RAM for each. 

Any iAPX 86 system must have ROM or EPROM at the 
upper end of memory to hold the CPU restart vector. 
About 3400 more bytes are consumed by code to initial- 
ize and access the OSP. This code is generated auto- 
matically from libraries on a diskette provided with a 
product called the iAPX 86/30 and iAPX 88/30 Operat- 
ing System Processor Support Package (iOSP 86 ). 
Space left in the initialization EPROMs is available for 
application tasks. 

As code is being written, the system designer should 
count on another 1500 bytes of code from the support 


libraries being added to his application during the link- 
ing and system configuration steps. These memory re- 
quirements are shown in Figure 6 . In practice, the 
separate blocks in this figure would be grouped together 
for more efficient use of RAM and EPROM chips. 
The 80130 occupies a 16K-byte block of addresses in the 
host-processor memory space, so external logic should 
decode address bits A 19 -A 14 to generate MEMOS. 
Similiarly, the timer and interrupt control logic occupy 
a 16-byte block of addresses in the I/O space; at least 
some of the bits ^15 -A 4 must be decoded to generate 
IOCS. The 80130 decodes all the lower-order address 
bits (14 for memory, four for I/O internally). 

Firmware in the 80130 leaves a great deal of flexibility in 
decoding the chip- select signals, to be compatible with 
whatever decode logic is already present in the system. 
The I/O starting address may be on any 16-byte bound- 
ary in the full CPU EO space. The memory block has 
only two restrictions; the off-chip initialization and in- 
terface code memory must be placed immediately 
above the MEMCS block, so the 80130 may not occupy 
the extreme top of memory, nor may the 80130 reside at 
address OOOOOH since this area is reserved for interrupt 
vectors. 
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Timing Requirements 

System timing analysis is often the most tedious part of 
digital hardware design. This discussion can be rela- 
tively short, though, because the 80130 timing is quite 
simple: by design, the part is compatible with the timing 
of the host processor. Since it interfaces directly with 
the CPU pins, traditional set-up, hold, and access times 
no longer matter. 

There are really only two areas of concern in analyzing 
the timing of most OSP systems, both of which relate to 
the user-generated chip-select signals. Figure 7 il- 
lustrates the relevant timing signals of a standard 8086 
four-state Read cycle (memory or I/O), along with the 
timing responses of the 80130. I/O Write cycle timing is 
the same. (Full timing diagrams are part of the respec- 
tive data sheets.) 


The first concern is that MEMCS and IOCS must be 
active early in a memory or I/O cycle if the 80130 is to 


respond during T 3 . In each case, the chip-select signals 
must be active Tcscl before the end of state T2. 
Assuming wait states aren’t desired, addresses 
generated by the CPU must propagate through the ad- 
dress latches and be decoded during Tj or T 2 . 

How much time does this leave the decode logic? As 
we’ll see, ample. 

By convention, T^l^V delay from the start of 

Ti until address information is valid on the CPU pins; 
Tjvov is the propagation delay through an 8282 latch; 
and Tcscl is the 80130 chip-select set-up time. The 
mnemonic Tqvcs represents the chip-select logic prop- 
agation delay, after the latch outputs are stable. The 
sum of these four delays must be less than two system 
clock cycles, reduced by the clock transition time. 

Tclav + Tjvov + Tovcs + Tcscl - Tclcl + Tclcl 

Tqvcs - Tclcl + Tclcl ~ Tclav ~ Tiyov ~ Tcscl 

< 125 +125 - 60 - 30 - 20 (nsec.) 

^ 140 nsec. 
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Figure 7. Operating System Processor Timing Diagrams 
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The propagation delay numbers plugged into the equa- 
tion are worst-case values from the appropriate Intel 
data sheets. The CPU is an 8086-2 operating at 8 MHz. 
This means the address decode logic must produce 
stable CS outputs within 140 nanoseconds. 


Exercise 2. Using standard, low-power Schottky 
TTL, does it make sense for a circuit to take 
longer than 140 nsec, to decode 6 program or 12 
I/O address bits? Even if the rather liberal setup 
specs are not met, the 80130 would still work fine. 
Wait states would be needed until the chip-select 
signal was active, however, so performance 
would degrade some. 


The second point of concern relates to ready signal 
timing. The 80130’s acknowledge output signal, ACK, 
can be used to control the CPU’s ready signal. For this 
case, the chip-select signal must be active early in a 
memory or I/O cycle to allow activation of ACK early 
enough to prevent wait states. There are two schemes 
for implementing ready signals; “normally ready” and 
“normally not ready.” (For more details, refer to AP- 
67, “8086 System Design.”) Chip-select timing is more 
critical in some “normally not ready” systems. 


In a “normally not ready” design, acknowledge signals 
are generated when each resource is accessed. The 
individual acknowledgements are combined to form a 
system-wide ready signal which is synchronized by the 
8284A clock generator via the RDY and AEN inputs. 
The 8284A can be strapped to accept asynchronous 
ready signals (asynchronous operation) or to accept 
synchronous ready signals (synchronous operation). 
Synchronous 8284 A operation provides more time for 
address latch propagation and chip-select decoding. In 
addition, inverting ACK off chip produces an active- 
high ready signal compatible with the 8284A RDY in- 
puts, which have shorter set-up requirements than 
AEN inputs. (As a side benefit, a NAND gate used like 
this can combine ACK with the active-low acknowl- 
edge signals from other parts of the system.) Based on 
these assumptions, the time available for address latch 
propagation and chip-select decoding at 8 MHz is: 

Tclav + Tovcs + Tcsak + Rrivcl - Tclcl + Tclcl 
Tqvcs - 2 Tclcl “ Tclav “ Tcsak “ Trivcl 
< 250 - 60 - 110 - 35 

^ 45 nsec. 


The circuit in Figure 8 which uses Schot tky TTL com- 
ponents leaves about 15 nsec, to produce MEMCS from 



Figure 8. High-Speed Address Decoding Circuit 
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the high-order address bits — more than enough for the 
74S138 one-of-eight decoder shown. 

Granted, this does not leave much leeway to fully 
decode the I/O address bits. A 12-input NAND gate on 
AD15-AD4 could be used, introducing only a single 
propagation delay but forcing the I/O register block to 
start at OFFFOH. Incomplete decoding is also legal: it is 
safe to drive IOCS with the (latched) AD 15 signal di- 
rectly, provided all other ports in the system are dis- 
abled when this bit is low. In this case, the effective 
address of the I/O block (which must be specified dur- 
ing the system configuration step) could be OOOOH, or 
any other multiple of 16 between OOOOH and 7FF0H. 

Again, the OSP system will still operate even if the 
memory or I/O decoding is slow. The acknowledge 
signal returned to the host CPU would just be delayed 
accordingly, so unnecessary wait states would be in- 
serted in access cycles, but the 80130 would not mal- 
function. Only rarely does the OSP access resources in 
its I/O space. Even if slow decode logic were to insert 
several wait states into every I/O cycle, the overall 
effect on system performance would be insignificant. 

A few words of caution, though. If the 8284 A is strap- 
ped for synchronous operation, external circuitry must 
guarantee that ready-input transitions don’t violate the 
latch set-up requirements. Also, the chip-select signal 
must not remain low so long after the address changes 
that the 80130 could respond to a non-80130 access 
cycle. 

Exercise 3. Suppose the typical timing values for 
a particular decoder would easily meet the ready- 
input set-up requirements presented above for 
asynchronous 8284 A operation, but pathological 
worst-case figures were just a little slow. Could 
that circuit still be used safely in most applica- 
tions? What would happen if the worst-case com- 
bination of worst-case conditions ever actually 
did occur? These occasional extra wait states 
would probably not cause a hard system failure. 

Exercise 4. Earlier it was mentioned that the ac- 
knowledge signal could also be used to avoid bus 
contention. Prove that with any decode logic 
which meets the above requirements, ACK would 
disable the bus transceivers before the host CPU 
samples the bus. 

Example System Design 

Appendix A includes full schematics for a complete 
iAPX 86/30 system providing considerable function- 
ality with only 27 chips. In addition to the OSP, the 


system has 4K bytes of 2114 RAM (with sockets for 
another 4K), from 8K to 32K bytes of 2732A or 2764 
EPROM, an 8251 A US ART operating at 9600 baud, and 
an 8255A Programmable Peripheral Interface with 24 
parallel I/O lines. Eight of the inputs read logic values 
off DIP switches; eight outputs drive small LEDs. Four 
more outputs connect to the coil drivers of a four-phase 
stepper motor. A layout diagram of the prototype ap- 
pears in Figure 9. 

The system is even simpler than the discussion of 
“typical” requirements implied. The 8086 direct-bus 
drive capability is adequate to make the data trans- 
ceivers unnecessary. (To equalize the bus loading, the 
8255A is connected to the upper half of the bus.) Ad- 
dress decoding logic was minimized by making the 
high-order address bits “don’t-cares.” Moreover, the 
part count could have been reduced to 16 using an 8088 
and multiplexed-bus 8185 RAMs and 8755A EPROMs. 
(The reader may be surprised to learn that, except for 
wire-wrapping mistakes, the prototype system hard- 
ware worked when it was first powered up. The author 
certainly was!) 

APPLICATION SOFTWARE 
DEVELOPMENT 

Like other well-structured programs, application 
software to run on the iAPX 86/30 is written as a num- 
ber of separate procedures or subroutines. In conven- 
tional programs, though, execution begins with a 
section of code (the program body) at the outermost 
level. The program calls application procedures, which 
may call other procedures, but which eventually run to 
completion and return to the program body. 

In an OSP application, though, there is no “outermost 
level” in the traditional sense; rather, the procedures 
are started, suspended, and resumed as situations war- 
rant under the control of the OSP. The term “task” 
refers to the execution of such a procedure in this way. 
While an instruction stream is suspended, the OSP 
keeps track of the task state (instruction counter, CPU 
register contents, etc.) so that it may be resumed later. 

Each task is assigned a relative priority by the program- 
mer, on a scale of 0 (high priority) to 255 (low). Tasks 
with higher (numerically lower) priority are given pref- 
erential treatment by the OSP; the task actually control- 
ling the CPU at any given instant will be the one with the 
highest priority which is not waiting for some event to 
occur. (If all this sounds confusing, examples coming 
later may help.) 

A task which operates independent of other tasks can 
be written without knowing anything about the others. 
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This makes it easy to divide a very large programming 
job among a team of programmers, each writing the 
code for some of the tasks. Moreover, a task need not 
even know if other tasks exist. They may be tested and 
debugged before others have even been written. As an 
application evolves, new tasks may be added or un- 
necessary ones removed without affecting the rest. 

The number of tasks in an application may need to be 
quite large. The number of tasks allowed in one applica- 
tion is essentially unlimited, as is the number of other 
objects — regions, mailboxes, segments, and the like. 
(The term “object” relates to different types of data 
structures maintained internally by the OSP.) Each ob- 
ject is internally identified by a unique 16-bit “token,” 
which means the theoretical maximum total is over 
65,000. The more pragmatic issue of physical memory 
consumption limits the number of simultaneous concur- 
rent tasks to “only” several thousand. 

(When a number of tasks cooperate to accomplish some 
common goal, the collection of tasks is referred to as an 
application “job.” The OSP also allows for an unlimited 
number of application jobs, though only one is il- 
lustrated in the example discussed here. A second 
similar machine, with different status switches, a differ- 


ent motor, and a different console might make up a 
second job.) 

All OSP application jobs must have one special in- 
itialization task (often called INIT$TASK) just to get 
started; this one may, in turn, create other tasks as it 
executes. The initialization task for this example is 
discussed at the end of this chapter. 


Hardware Initialization 

The life of any task can be broken into three phases: 
start-up, execution, and termination. The start-up 
phase initializes variables, data structures, and other 
objects needed by the task. During the execution phase 
the task performs its useful work. Depending on the 
application, this may be a single sequence of actions, or 
a loop executed repeatedly. When the task completes, it 
must terminate itself so as not to use any more CPU 
time. One or more phases may be omitted. For exam- 
ple, some tasks are intended to execute “forever,” in 
which case the termination phase is not required. 

This life cycle is suggested by Example 1 , a segment of 
code called HARDWARE$INIT$TASK. This task first 
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programs the 80130 internal timer logic to generate a 
square-wave cycle on the BAUD pin every 52 system 
clock cycles, which corresponds to a system console 
data rate of 9600 baud. The task then sets the system’s 
8255A PPI and 8251AUSART devices to operate in the 
desired modes, and outputs a short sign-on message to 
the CRT. For the sake of reader’s unfamiliar with the 
protocol for interfacing with the 8251 A, simple input 
and output routines (C$IN and C$OUT) are reproduced 
in Example 2. 


HARDWARE* IN1T*T ASK: PROCEDUREi 

DECLARE HARD*INIT*EXCEPT*CODE WORD; 

DECLARE PARAM*S1 (*) BYTE DATA ( 40H, SDH, OOH. 40H, 4EH, 27H ) ; 

DECLARE PARAM*51*INDEX BYTEi 

DECLARE S10N*ON*MESSAOE <*> BYTE DATA 

(CR.LF, 'iAPX 8&/30 HARDWARE INI T I ALI ZED ' , CR , LF ) ; 

DECLARE SION*ON*INDEX BYTE; 

OUTPUT ( PP I *CMD ) =90Hi 
OUTPUT ( T 1 MER*CMD ) =0B6Hi 

0UTPUT<BAUD*TIMER)*33; /^GENERATES 9600 BAUD FROM 5 MHZ*/ 
0UTPUT<BAUD*TIMER)=0; 

DO PARAM*S1*INDEX=0 TO (SIZE(PARAM*51 )-l >, 

OUTPUT ( CMD*5 1 > -PAR AM*5 1 < P AR AM*5 1 * I NDEX ) i 
ENDi /*OF USART INITIALIZATION DO-LOOP*/ 

DO SI0N*0N*INDEX=O TO ( SI ZE( SIQN*ON*MEBSAGE ) -1 ) i 
CALL C«0UT(SIGN»0N«MESSA6E<SIGN*0N*INDEX) )i 
END; /*OF SICN-ON DO-LOOP*/ 

CALL RQ*RESUME*TASK(INIT*TASK*TOKEN, ©HARD* INIT*EXCEPT*CODE ) i 
CALL RQ*DELETE*TASK(0, ®HARD*INIT*EXCEPT*CODE) ; 

END HARDWARE*INIT*TASK; 

Example 1. System Hardware Initialization Task 


C*0UT: PROCEDURE (CHAR)i 

DECLARE CHAR BYTEi 

DO WHILE ( INPUT(STAT*5n AND 01H)=Oi 
/* NOTHING */ 

END; 

OUTPUT ( CHAR*51 ) -CHAR i 
END C*OUTi 

C*IN: PROCEDURE BYTEi 

DO WHILE <1NPUT<STAT*51 ) AND 02H)=0i 
/* NOTHING */ 

ENDi 

RETURN INPUT(CHAR*51>i 
END C«INi 

Exampie 2. Simple 8251A Input and Output 
Routines 


The baud timer should be initialized by a code sequence 
like that shown here. The 80130 logic is actually com- 
patible with the initialization sequence which would be 
needed to configure timer 2 of an 8253 A as a program- 
mable rate generator. The baud rate parameter loaded 
into the timer is simply the system clock frequency 
divided by the desired output frequency. No other 
timers should be affected by user programs. 


When the hardware has been initialized, the task 
calls an operating system procedure called RQ$ 
RESUME$TASK. This signals the OSP that the task’s 
start-up phase has completed, and that the initialization 
task (which in this case suspended itself after creating 
HARD$INIT$TASK) may continue. Since its function 
is hardware initialization only, HARD$INIT$TASK 
has no execution phase per se . It terminates by calling 


the procedure RQ$DELETE$TASK, suicidally 
specifying itself as the task to be deleted. 

Exercise 5. Beginners may make two common 
programming errors when developing OSP tasks. 
The first is when a task deletes itself without ever 
resuming the suspended task that created it. The 
second is to not terminate a task properly, with the 
result that the processor executes a return in- 
struction when the task’s work is done. (However, 
execution of the task did not originate with a call 
from the OS.) As with all computers, an OSP will 
do exactly what it is told. How do you suppose the 
system would react in each case? (Hint: only one 
of the two failure modes is predictable.) 

You may have noticed three things from this short ex- 
ample and Table 1. First, every OSP call begins with 
the letters RQ. (PL/M compilers totally ignore dollar 
signs within symbols; they serve only to split long sym- 
bol names to make them easier for humans to read.) The 
letters RQ don’t mean anything in particular; their pur- 
pose is to make sure OSP routine names don’t conflict 
with any user symbols. These particular letters were 
chosen to be compatible with the historical naming 
convention used by iRMX 86. It may be useful, though, 
to think of RQ as an abbreviation for REQUEST, imply- 
ing that the OSP provides useful services at the bidding 
of application code. 

The second thing to notice is that the OSP routine 
names imply pretty well what each routine does. On the 
one hand, long procedure names take a little longer to 
type; on the other, they make code listings much easier 
to read and understand. In effect, the long names help 
make OSP code self-documenting. The long names 
shouldn’t hinder code development; rarely can pro- 
grammers think faster than they can type. If they could, 
programmer productivity would be measured in 
thousands of lines per day. 

The third thing is that the last parameter in every OSP 
system call points to a word in which the OSP proce- 
dure will return an exception code to the application 
task. The procedure will return a non-zero exception 
code in this word if it cannot do its job correctly. This 
does not always imply that an error occurred; some- 
times it just means another task isn’t ready to cooperate 
yet. Sometimes an exception value indicates whether 
the OSP request was processed immediately or delayed 
for some reason. In fact, some OSP routines are guaran- 
teed never to return a non-zero exception code, yet the 
pointer is still required for the sake of consistancy. For 
a full explanation of the other parameters for the OSP 
procedures and details on what the different exception 
codes mean, consult the iAFX 86130, 88130 User’s 
Manual. 
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To illustrate how the OSP procedures are used, the 
following code examples implement the machine con- 
troller tasks introduced earlier. Appendix B puts all the 
code examples together, though not in the exact order 
discussed. Be Forewarned: the examples border on 
trivial. They are in this note to demonstrate how to call 
system routines with as few lines of code as possible, 
not to tax the capabilities of the OSP. In fact, none of the 
tasks even check for exception codes returned by the 
OSP, under the naive assumption that nothing will go 
wrong in a debugged program. If you’re interested in 
more elaborate software examples, consult application 
notes AP-86 and AP-1 10. These notes focus specifically 
on iRMX 86, but their methods and much of the code 
apply equally to the OSP systems. 


Simple Time Delays 

The STATUS$TASK routine simply monitors eight 
switches through an input port, and updates eight 
LEDs with a pattern determined by the switch settings 
and task status. Specifically, the LEDs display the bit- 
wise Exclusive-OR function of the inputs and an eight- 
bit software counter maintained by the task. This action 
will repeat twice per second. The task does nothing 
between iterations. 

The RQ$SLEEP routine gives application tasks a way 
to release the CPU when it is not needed. Any task 
calling this routine is “put to sleep” for the amount of 
time it specifies (from 1 to 65,000 SYSTICK intervals), 
releasing the CPU to service other tasks in the mean- 
time. After the requested time has transpired, the OSP 
task will reawaken the task and resume its execution, 
provided a more important task is not then executing. 

The 80130 timer logic generates the fundamental Sys- 
tem Tick by dividing the system clock frequency by 
two, then subdividing that frequency by a 16-bit value 
specified during the configuration process. The period 
used here is 5 msec., which would result in an 5 MHz 
system by dividing the 2.5 MHz internal frequency by 
12,500. 


Exercise 6: At this rate, what’s the longest nap 
that would result from a single call to 
RQ$SLEEP? How could this duration be 
extended? 


PL/M listings for the complete STATUS$TASK routine 
appear in Example 3. 


STATUS»TASK: PROCEDURE^ 

DECLARE STATUS*COUNTER BYTE; 

DECLARE STATUS*EXCEPT*CODE WORD; 

STATUS«COUNTER*0; 

CALL RQ*RESUME*TASK ( INIT»TASK*TOKEN, eSTAYUS*EXCEPT$CODE ) ; 
DO FOREVER; 

OUTPUT(PPI*B)=INPUT(PPI»A) XOR StATUS$COUNTER; 
STATUS*C0UNTER-STATUS$C0UNTER+1; 

CALL RQ$SLEEP< lOOi eSTATUS*EXCEPT*CODE); 

END; 

END STATUS^TASK; 

Example 3. Status Polling and Reporting Tdsk 


Stepper Motor Control 


Conceptually, a stepper motor consists of four coils 
spaced evenly around a rotating permanent magnet. By 
energizing the coils in various combinations, the mag- 
net can be induced to align itself with the coils, individu- 
ally or in pairs. A microcomputer can make a stepper 
motor rotate, step-by-step, in either direction, by emit- 
ting appropriate coil control signal patterns at intervals 
corresponding to the step rate. 

The stepper-motor sequencer (Example 4) is an embel- 
lished version of STATUS$TASK. The OSP calls are 
intermixed with a few more statements of application 
code, and the task uses global variables as delay 
parameters. The reader may wish to adapt the com- 
mand interpreter task at the end of this chapter to let the 
operator modify (read: “play with”) these parameters 
to adjust the motor speed as the program runs. 


DECLARE CW*STEP»DELAY BYTE, 

ccw^step^delay byte, 

CW»PAUSE*DELAV BYTE, 

CCW*PAUSE*DELAY BYTE; 

MOTOR*TASK: PROCEDURE; 

DECLARE M0T0R»EXCEPT*C0DE WORD; 

DECLARE M0T0R*P0SITI0N BYTE, 

MOTOR *PHASE BYTE; 

DECLARE PHASE$C0DE (4) BYTE 

DATA (OOOOOIOIB, 000001 lOB, OOOOlOlOB, OOOOIOOIB); 

CW»STEPitDELAY=50; /^INITIAL STEP DELAYS «= 1/4 SECOND^/ 
CCW4iSTEP*DELAY*=50; 

CW»PAUSE»DELAY=!200; /^PAUSES AFTER ROTATION 1 SECOND*/ 
CCW$PAUSE*DELAY“200; 

CALL RQ$RESUME»TASK(INIT*TASK»TOKEN, @MDT0R*EXCEPT*C0DE ) ; 

DO FOREVER; 

DO MOTOR*POSITION*0 TO 100; 

M0T0R«PHASE=M0T0R*P0SITI0N and 0003H; 

OUTPUT ( PP I *C ) *PHASE*CODE < M0T0R$PHA9E > ; 

CALL RQ*SLEEP<CW»STEP*DELAY, eM0T0R*EXCEPT*C0DE J ; 
END; 

CALL RQ»SLEEP(CW*PAUSE»DELAY, eM0T0R*EXCEPT*CaD£ ) ; 

DO MOTOR^POSlTIONsO TO 100; 

MOTOR#PHASE==<10O-M0TOR*P0SlT.tON) AND 0003H; 

OUTPUT ( PP I $C ) aPHASE*CODE ( MOTOR*PHASE ) ; 

CALL RQ»SLEEP ( CCW*STEP$DELAY, ®MDTOR*EXCEPT$CODE ) , 
END; 

CALL RO»SLEEP(CCW*PAUSE«DELAY, @MOTOR*EXCEPT»CODE ) ; 

END; 

END M0T0R*TASK; 

Example 4. Stepper-Motor Controller Task 


Real-Time Interrupt Processing 


The 80130 supports a two-tiered hierarchy of interrupt 
processing. The lower-level tier corresponds to the 


15 


AFN-02058A 



AP-130 


traditional concept of hardware interrupt servicing; a 
routine called an “Interrupt Handler” is invoked by the 
80130 internal interrupt control logic for immediate 
response to asynchronous external events. A short 
routine like this might, for example, move one charac- 
ter from a US ART to a buffer. Interrupt handlers oper- 
ate with lower-priority interrupts disabled, so it is a 
good idea to keep these routines as quick as possible. 

“Interrupt Tasks,” on the other hand, are higher-level 
tasks which sit idle until “released” by an interrupt 
handler. The task then executes along with other active 
tasks, under the control of the OSR Such a task should 
be used to perform slower but less time-critical pro- 
cessing when occasions warrant, such as when the 
aforementioned buffer is full. Moving such additional 
processing outside the hardware-invoked interrupt 
handler reduces the worst-case interrupt processing 
time. 

This hierarchy also decreases interrupt latency. Most 
OSP primitives execute in their own, private 
“environment” (e.g., with their own stack and data 
segments) rather than that of the calling task. Interrupt 
handlers, on the other hand, run in the same environ- 
ment as the interrupted task. (In fact, the 80130 
primitives may themselves be interrupted!) Leaving the 
CPU segment registers unchanged minimizes software 
overhead and interrupt response time, but also means 
that interrupt handlers may not call certain OS 
routines. An interrupt task, on the other hand, is in- 
itiated and suspended by the OSP itself, with no such 
restrictions. 

Let’s see how these capabilities would be used. The 
time delays introduced by the RQ$SLEEP call are only 
as accurate as the crystal frequency from which they 
are ultimately derived. This may not be exact enough 
for critical time-keeping applications, since oscillators 
vary slightly with temperature and power fluctuation. 

To keep track of the time of day, the example system 
uses a 60-Hz A.C. signal as its time base. (Most power 
utility companies carefully regulate line frequency to 
exactly 60 Hz, averaged over time.) A signal from the 
power supply is made TTL-compatible to drive one of 
the 80130 interrupt request pins. An interrupt handler 
responds to the interrupts, keeping track of one 
second’s worth of A.C. cycles. An interrupt task counts 
the seconds by incrementing a series of variables. 

Example 5 illustrates the former routine. AC$ 
HANDLER simply increments a variable on each 60- 
Hz interrupt. Upon reaching 60, it clears the counter 
and signals TIME$TASK (Example 6). 


DECLARE AC*CYCLE*COUNT BYTE; 

AC*HANDLER: PROCEDURE INTERRUPT 59; /*UECTDR FOR 80130 INT3*/ 

DECLARE AC*EXCEPT*CODE WORD; 

CALL RQ*ENTER*INTERRUPT< AC»1NTERRUPT*LEYEL, ®AC»EXCEPT*COD£ ) ; 
AC*CYCLE*COUNT=AC*CYCLE*COUNT+ 1 ; 

IF AC*CYCLE*COUNT >= 60 
THEN DO; 

AC*CYCLE»COUNT=0; 

CALL RQ»SIGNAL*INTERRUPT(AC»INTERRUPT»LEVEL, 
®AC»EXCEPT»CODE); 

END; 

ELSE CALL RQ*EX IT*INTERRUPT ( AC* INTERRUPT$LEVEL, 
@AC*EXCEPT*CDDE) ; 

END AC*HANDLER; 

Example 5. 60-Hz A.C. Interrupt Handler 


In its initialization phase, TIME$TASK sets up the 
interrupt handler by calling the RQ$SET$ 
INTERRUPT routine. The body of TIME$TASK (the 
execution phase) is just a series of nested loops count- 
ing hours, minutes, and seconds. When TIME$TASK 
calls RQ$WAIT$INTERRUPT inside its inner-most 
loop, the OSP suspends execution of the task until 
AC$HANDLER signals that another second’s worth 
of A.C. cycles has elapsed. Thus, interrupt handlers 
can serve to “pace” interrupt tasks. After a day, 
TIME$TASK completes and deletes itself. 

DECLARE SECOND*COUNT BYTE, 

MINUTESCOUNT BYTE, 

HOUR*COUNT BYTE; 

T1ME*TASK; PROCEDURE; 

DECLARE TIME»EXCEPT*CODE WORD; 

AC*CYCLE$C0UNT=0; 

CALL RQ*SET*INTERRUPT(AC»INTERRUPT*LEVEL, OlH, 

INTERRUPT$PTR(AC$HANDLER), DATA*SEG*ADDR . BASE, 
®TIME*EXCEPT*CODE); 

CALL RQ$RESUME*TASK( INIT»TASK»TOKEN, @TIME$EXCEPT$CODE ) ; 

DO H0UR*C0UNT=0 TO 23; 

DO MINUTE*C0UNT=0 TO 59; 

DO SEC0ND»C0UNT=0 TO 59; 

CALL RQ*WAIT$INTERRUPT(AC$INTERRUPT$LEVEL, 
eTIME*EXCEPT$CODE); 

IF SECONDtCOUNT MOD 5=0 

THEN CALL PROTECTED*CRT$OUT ( BEL ) ; 

END; /* SECOND LOOP «■/' 

END; /* MINUTE LOOP */ 

END; /* HOUR LOOP */ 

CALL RQ*RESET»INTERRUPT(AC*INTERRUPT»LEVEL, 
@TIME*EXCEPT*CDDE ) ; 

CALL RQ*DELETE*TASK(0, ©T I ME*EXCEPT*CODE ) ; 

END TIME*TASK; 

Example 6. Interrupt Task to Maintain Time of Day 


Exercise 7: The time maintained by TIME$TASK 
is consistently wrong, unless the system resets at 
midnight. Aside from that, how much error would 
accumulate per month hadTIME$TASK paced its 
inner loop by calling RQ$ SLEEP if the system 
oscillator was 00.01% off? How does this com- 
pare with a cheap digital watch? How much error 
will accumulate from the 60-Hz time base 
described? 


TIME$TASK incorporates another gimmick: every five 
seconds it sends an ASCII “BEL” character (07H) to 
the console to make it beep, by calling a routine called 
PROTECTED$OUTPUT. This lead-in gives us a 
chance to discuss OSP provisions for task synchroniza- 
tion and mutual exclusion. 
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Mutual Exclusion 

Whenever system resources (e.g., the console) are 
shared among multiple concurrent tasks, the software 
designer must be aware of the potential for conflicts. In 
single-threaded (as opposed to multitasking) programs, 
the easiest way to transmit characters is by calling a 
console output routine (written by the user or supplied 
by the OS) which outputs the character code. 
(Remember the examples following the hardware in- 
itialization routine?) 

This approach presents two problems in a multitasking 
system. One is efficiency: a high-priority task could 
hang up the whole system while it waits for a printer 
solenoid to energize, induce a magnetic field, accelerate 
the hammer, contact a daisy- wheel spoke, move it up to 
the ribbon, and press them both against the paper. This 
waste of time is termed “busy waiting,” and should 
always be avoided. By OSP standards, even 1/30 of a 
second can seem interminable; if the printer is other- 
wise occupied, the whole system could shut down 
indefinitely. 

Aside from efficiency, though, there is a more serious 
synchronization problem here. Assume Task A has a 
higher priority than Task B. Task A is asleep. Task B 
calls a subroutine to poll the US ART and transmit a 
character. The US ART becomes ready. When this is 
detected, the subroutine prepares to output the charac- 
ter to the US ART .... 

Time out! Task A just woke up and starts running. Task 
A wants to transmit its own character. It calls its own 
output routine, checks the US ART, finds it available, 
sends it a new character, and goes back to sleep 
(or suspends itself, or awaits another interrupt — 
whatever). 

Now Task B continues. It “knows” the USART is 
available, having dutifully monitored it earlier. Task B’s 
character goes out to the USART. The USART goes out 
to lunch. (In practice, the USART will probably just 
transmit corrupted data; still, its operating require- 
ments have been violated.) 

In Task B’s output routine, the sequence of statements 
from when the peripheral is found to be ready to when 
the next character is written constitutes a “critical 
region” (a.k.a. “critical section” or “non-interruptable 
sequence”). Recognizing such regions and handling 
them correctly is an important concern in any multi- 
tasking system, so the OSP provides several facilities 
— interrupt control, regions and mailboxes— to help 
handle general synchronization and mutual exclusion 
problems. Which one to choose depends on the 
circumstance. 


Exercise 8: In this example, would it be better if 
Tasks A and B shared a single output routine, so 
that only one section of code sent data to the 
USART? Convince yourself that the same (or 
worse!) problems could still arise. 

Sometimes critical sections can be protected by just 
disabling interrupts at appropriate points in the applica- 
tion software. To maintain the integrity of an iAPX 
86/30 system, application code must never execute the 
STI, CLI, or HLT instructions (ENABLE, DISABLE, 
or HALT statements in PL/M), nor can it access the 
interrupt control logic directly. Instead, the interrupt 
status should be controlled with the OSP 
RQSENABLE and RQ$DISABLE procedures; 
routines should be halted via RQ$SUSPEND or 
RQ$WAIT$INTERRUPT. 

Back toTIME$TASK: we want to transmit BELs to the 
console every five seconds. The console output task 
will be transmitting other characters. A “clever” pro- 
grammer may recognize that this will lead to a critical 
section and analyze the situation as follows: 

1. A hazard would arise if TIME$TASK sends out a 
beep when CONSOLE$OUT$TASK is using the 
USART; 

2. TIME$TASK will only execute after being signaled 
by A$C$HANDLER; 

3. A$C$HANDLER only reponds to an external 
interrupt. 

“Therefore, all CONSOLE$OUT$TASK has to do to 
be safe is disable the 60-Hz interrupt around its output 
routine.” 

Not quite. There are still potential hazards. Suppose 
CRT$OUT$TASK has the same priority as 
TIME$TASK. TIME$TASK may already have been 
signaled by A$C$HANDLER and be ready to run when 
CRT$OUT$TASK completes. An otherwise unrelated 
event — another interrupt, for instance — could mo- 
mentarily suspend CRT$OUT$TASK during the criti- 
cal region with A. C. interrupts disabled. When the OSP 
returns to that level, it might resume with 
TIME$TASK, not CRT$OUT$TASK. This could lead 
to the same malfunctions as before, so disabling 60-Hz 
interrupts didn’t help. This series of worst-case as- 
sumptions is admittedly convoluted, but the resulting 
sporadic errors are among the hardest of all bugs to 
squash. 

The problem is that this attempted solution involves too 
much interaction between tasks, making it confusing 
and error-prone. Even if some scheme of priority-level 
assignments and task interactions could be made to 
work, later modifications or simple additions to the job 
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could cause bugs to reappear. (The analogy of an unex- 
ploded time bomb comes to mind.) 

A simpler solution would be one corresponding more 
closely with the problem. Accordingly, the OSP sup- 
ports several primitives just to supervise and control 
access to critical regions. 

One of the OSP “data types” is a data structure called a 
“Region,” which can be used by application code to 
control access to a shared port or some other resource. 
A task wishing access to the resource should call the 
OSP procedure RQ$RECEIVE$CONTROL before 
trying to access that resource; when done it must call 
RQ$SEND$CONTROL. 

The OSP keeps track of which regions are in use. As 
long as a region is busy (i.e., has been entered but not 
yet exited), the OSP will prevent other tasks from enter- 
ing the region by putting them to sleep. The OSP keeps a 
queue of all tasks waiting for the busy region. When the 
region later becomes available (i.e., when the task con- 
trolling the region calls RQ$SEND$CONTROL), one 
of the sleeping tasks — either the highest priority or the 
most patient — will be awakened, granted control of the 
region, and sent on its way. (When a region is created, 
the OSP is told whether to awaken tasks waiting for the 
region based on their priority or how long they 
have been waiting.) Effectively, a call to RQ$ 
RECEIVE$CONTROL will not return to the applica- 
tion task until the resource in question becomes 
available. 

The PROTECTED$CRT$OUTPUT (Example 7) dem- 
onstrates this protocol. The routine is declared 
reentrant which means (by definition) the routine may 
be interrupted and restarted safely. A reentrant routine 
may be shared by a number of tasks, instead of replicat- 
ing the same code throughout the application. 


PROTECTED$CRT4iOUT: PROCEDURE (CHAR) REENTRANT; 

DECLARE CHAR BYTE; 

DECLARE CRT»EXCEPT*CODE WORD; 

CALL RQ»RECEIVE*CONTROL(CRT»REGIONtTOKEN, aCRT*EXCEPT$CODE ) ; 
DO WHILE < INPUT (STAT*51 ) AND 01H)=0; 

/* NOTHING */ 

END; 

OUTPUT (CHAR* 51 )=CHAR; 

CALL RQ*SEND*CONTROL ( ®CRT*EXCEPT*CODE ) ; 

END PROTECTED*CRT*OUT; 

Example 7. CRT Output Routine Protected by 
Region Protocol 


As a concession to simplicity, PROTECTED$ 
CRT$OUTPUT does use a form of the busy waiting 
method described earlier. The maximum delay at 9600 


baud is only one millisecond, however, much shorter 
than a system tick. Besides, tasks performing character 
I/O will all have low priority levels, so the OSP would 
just delay them if anything more urgent comes up. 

Exercise 9: Decide whether this explanation is a 
feeble attempt at rationalization, or a well- 
justified engineering trade-off. 

Inter-Task Communication 

But what if a high priority task must output a string of 
characters, or the peripheral response time is too long? 
Busy-waiting may not be acceptable. Alternatively, the 
output routine could buffer the data and service the 
US ART within an interrupt routine. Another would be 
to simply pass the data off to a special (low-priority) 
output task and continue. 

Tasks pass information to each other via something 
called a “message.” A message may be the token for 
any type of OSP object, but the most common and most 
flexible type is called a “memory segment.” In our 
example, segments will be used to carry strings of 
ASCII characters between tasks, so weTl examine seg- 
ments first. Message formats are defined by the individ- 
ual application programmer — make sure the sending 
and receiving tasks assume the same format! 

A memory segment is just a section of contiguous-sys- 
tem RAM allocated (set aside) by the OSP at the re- 
quest of an executing task. The OSP keeps track of a 
free memory “pool,” which is initially all unused RAM 
in the system. When a task needs some RAM, it tells the 
RQ$CREATE$SEGMENT procedure how much it 
wants. The OSP finds a suitable memory block in the 
pool, and returns a 16-bit token defining its location. (If 
not enough memory is available, the procedure returns 
an exception code.) 

The token is the base portion of pointer to the first 
usable byte of the segment, with the offset portion 
assumed to be zero. (The token values for all other 
objects have no physical significance.) Knowing this, 
it’s possible to access elements of the segment as the 
application warrants. 

The subroutine in Example 8 shows how to request a 
segment and construct a message. PRINT$TIME sends 
the ASCII values of the time-of-day counters 
(maintained in TIME$TASK) to the CRT output task 
described later. The message format adopted for these 
examples will consist of a byte giving the message 
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length, followed by that number of ASCII characters. 
Figure 10 shows this format. 


PRINTitTOD: PROCEDURE; 

DECLARE TQD*MESSAGE*TOKEN WORD; 

DECLARE TDD*EXCEPT*CODE WORD; 

DECLARE TOD»SEGMENT*OFFSET WORD, 

TOD*SEGMENT*BASE WORD; 

DECLARE TODSSEGMENTUPNTR POINTER AT < @TDD$SEGMENT9;OFFSE D ; 
DECLARE TOD*TEMPLATE (28) BYTE 

DATA <27, 'THE TIME IS NOW hh;mm: ss. ',CR,LF); 

DECLARE TOD»STRING BASED TOD*SEGMENT*PNTR (28) BYTE; 
DECLARE TOD»STRING*INDEX BYTE; 

T0D*MESSAGE»T0KEN=RQ*CREATE*SEGMENT(2B, @TOD»EXCEPT*CODE ) ; 
TOD»SEGMENT»BASE=TOD»MESSAGE«TOKEN; 

TOD*SEGMENT$OFFSET=0; 

DO T0D«STRING»INDEX=O TO 27; 

TQD*STRING(TOD*STRING*INDEX)= 

TOD*TEMPLATE ( TOD* STR I NG* 1 NDE X ) ; 

END; 

TOD*STR I NG ( 1 7 ) =ASC 1 1 *CODE ( HOUR»COUNT/ J. 0 ) ; 

TOD*STRING( 18)=»ASCII*C0DE<H0UR*C0UNT MOD 10); 

TODtSTR I NG < 20 ) =ASC 1 1 *CODE < M I NUTE»COUN T / 1 0 ) ; 
T0D*STRING(21)=ASCII*C0DE(MINUTE*C0UNT MOD 10); 

TOD*STR ING ( 23) =ASC I I*CODE ( SECOND*COUNT/ 10 ) ; 
T0D*STR1NG(24)=ASC1I*C0DE(SEC0ND*C0UNT MOD 10); 

CALL RQ*SEND*MESSAGE ( CRT*MAILBOX*TOKEN, 

TOD*MESSAGE*TOKEN, O, eTOD*EXCEPT*CODE ) ; 

RETURN; 

END PRINT*TOD; 

Example 8. Subroutine to Send Time-of-Day 
Message to Output Task 


We’re coding PRINT$TIME here (see Example 8), 
while TIME$TASK is fresh in our minds. It will actually 
be called by (and is therefore considered a part of) 
KEYBOARD$TASK. Note that while tasks are written 
as individual procedures, they need not be fully self- 
contained; outside procedures should be used to help 
organize and structure the code. 


The first thing PRINT$TIME does is have the OSP 
create a segment of suitable length, and copies a 
“message template” into the segment, byte by byte. 
Then it converts the TIME$TASK counter values to 
ASCII, filling in blanks in the template. Finally, it sends 
the token for the message to the CRT mailbox. 


To repeat, these examples are intended to illustrate use 
of the OSP routines assuming minimum familiarity with 
PL/M. Better programming practices might take advan- 
tage of PL/M literals, structures and the array 
LENGTH function to build the message, rather than 
the inflexible constants shown here. Some of these 
techniques are suggested by PRINT$STATUS 
(Example 9), which indicates the binary status of the 
input switches. 


PRINT*STATUS: PROCEDURE; 

DECLARE STATUS*MESSAGE*TOKEN WORD; 

DECLARE STATUS*EXCEPT*CODE WORD; 

DECLARE STATUS*SEGMENT*OFFSET WORD, 

STATUS*SEGMENT*BASE WORD; 

DECLARE STATUS*SEOMENT»PNTR POINTER 
AT <@STATUS*SEGMENT*OFFSET);- 
DECLARE STATUS*TEMPLATE (40) BYTE DATA 

<39, 'THE SWITCHES ARE NOW SET TO B',CR,LF); 

DECLARE STATUS*STRING BASED STATUS*SEGMENT*PNTR (40) BYTE; 
DECLARE STATUS*STRING*INDEX BYTE; 

DECLARE BIT*PATTERN BYTE; 

STATUS*MESSAGE*TOKEN=RQ»CREATE*SEGMENT <40, 
@STATUS*EXCEPT*CODE ) ; 
STATUS*SEGMENT*BASE=STATUS»MESSAGE*TOKEN; 
STATUS*SEGMENT*OFFSET=0; 

DO STATUS*STR1NG*INDEX=0 TO 39; 

STATUS*STR I NG ( STATUS4STR I NG* INDEX ) = 

STATUS*TEMPLATE ( STATUS*STRING*INDEX ) ; 

END; 

B I T*PATTERN= I NPUT ( PP I *A ) ; 

DO STATUS*STRING*INDEX=29 TO 36; 

STATUS*STR I NG ( STATUS*STR 1N0*INDEX ) = 
ASCII*CODE(BIT*PATTERN AND OlH); 
BIT*PATTERN=ROR(BIT*PATTERN, 1); 

END; 

CALL RQ*SEND*MESSAGE(CRT*MAILBOX*TOKEN, 

STATUS*MESSAGE*TOKEN, 0, ®STATUS*EXCEPT*CODE ) ; 

END PRINT*STATUS; 

Example 9. Subroutine to Send Status Report 
Message to Output Task 


Exercise 10: One input port is read by both 
STATUS$TASK and PRINT$STATUS. Does this 
constitute a shared resource? A critical region? 


Exercise 11: PRINT$TIME reads the counts 
maintained by TIME$TASK, but doesn’t alter 
them. Forced mutual exclusion is generally 
mandatory when multiple tasks perform 
read/modify/write sequences on a given variable. 
Can PRINT$TIME make TIME$TASK malfunc- 
tion? What about the opposite case? If this failure 
mode was deemed unacceptable, how could it be 
protected? 


Mailboxes 


The data in a message doesn’t actually move or get 
copied from source to destination when the message is 
sent; this would be too slow with long messages. 
Rather, the OSP “carries” the message’s token from 
task to task via a data structure cleverly termed a 
mailbox. If one task must send messages to another, a 
mailbox must be created to hold them. The sender calls 
the RQ$SEND$MESSAGE to put a message 
token into the mailbox. If the receiver isn’t ready for 
the message yet, the OSP puts the message token 
into an ordered queue. When the receiver calls RQ$ 
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RECEIVE$MESSAGE later, the OSP will give it the 
tokens one at a time. 

What happens if a task tries to receive a message when 
the mailbox is empty? (This is quite possible, since 
tasks do run asynchronously.) What token would the 
OSP return? 

In the simple case ... it doesn’t! Instead of returning 
right away with no data, the OSP will wait until data/5 
available. In the meantime, the OSP puts the receiving 
task to sleep, remembering that it is waiting for a 
message at that mailbox. The next time a message is 
sent to that mailbox, the OSP will awaken the receiving 
task, give it the token, and — if its priority is high 
enough— resume its execution. Alternatively, receiving 
tasks may elect to not wait if the mailbox is empty, or to 
wait only a specified time. 

Many tasks may actually send and receive messages 
through a single mailbox, with messages being queued 
in the order that the RQ$SEND$MESSAGE calls are 
executed. The OSP also maintains a list of tasks waiting 
to receive messages from an empty mailbox, analogous 
to the queued tasks waiting for region control. As each 
message is sent to the mailbox, it is passed immediately 
to a waiting task, either the one waiting the longest or 
the one with the highest priority (likewise determined 
by a parameter specified when the mailbox is created). 

Exercise 12: Under what conditions could a mail- 
box’s message queue contain messages waiting to 
be received, while the task queue contains tasks 
waiting for messages? Ignore the possibility that 
this may happen momentarily during the imple- 
mentation of either routine. If you think of any 
such circumstances, please contact the author. 

Example 10 shows a task which prints the messages 
sent above. Upon receiving a message token, 
CRT$OUT$TASK determines the message length from 
the first two bytes, and sequentially prints each element 
of the string through the PROTECTED$CRT$ 
OUTPUT routine explained earlier. When done, the 
segment containing the message is deleted, returning its 
RAM to the free-memory pool. 


A few words are in order about the segment accessing 
techniques demonstrated here. PL/M-86 has a special 
data type, called a “pointer,” used to indirectly access 
other PL/M variables. OSP application programs must 
be compiled with the “compact” or “large” model spe- 
cified. This tells the compiler to implement pointers as 
32-bit double words corresponding to the two parts 
(base:offset) of the 8086 machine- segmented address- 
ing scheme. PL/M-86 tries to shield the programmer 


CRT*OUT*TASK; PROCEDURE; 

DECLARE MESSAGE*LENGTH BYTE; 

DECLARE MESSAGE*TOKEN WORD; 

DECLARE RESPONSE^TOKEN WORD; 

DECLARE MESSAGE*EXCEPT$CODE WORD; 

DECLARE MESSAGE»SEGMENT»OFFSET WORD, 

MESSAGE»SEGMENT*BABE WORD; 

DECLARE MESSAGE*SEGMENT»PNTR POINTER AT 
( eMESSAGE»SEGMENT*DFFSET ) ; 

DECLARE MESSAGE*STRING»CHAR BASED MESSAGE»SEGMENT«PNTR BYTE; 

CALL RQ*RESUME*TASK(INIT$TABK$T0KEN, @MESSAGE*EXCEPT*C0DE ) ; 

DO FOREVER; 

MEBBAGE*T0KEN=RQ»RECEIVE»MESSAGE(CRT$MAILB0X*T0K.EN, offffh, 
aREBPONSE*TOKEN, @MESBAGE»EXCEPT*CODE ) ; 
MESSAGE*SEGMENT*OFFSET=0; 
MESSAOE*SEGMENT*BASE=MEBSAGE*TOKEN; 
MEBBAGE$LENGTH=MEBSAGE»STRING$CHAR; 

DO MEBSAGE*SEGMENT*OFFBET=l TO MESSAGE*LENGTH; 

CALL PRDTECTED*CRT»OUT ( MEBSAGE$BTR ING*CHAR ) ; 

END; 

CALL RQ»DELETE*SEGMENT(MESSAGE«TDKEN, @MESSAGE»EXCEPT*CDDE ) 
END; /* OF FOREVER-LOOP #/ 

END CRT*OUT*TABK; 

Example 10. Task to Transmit Messages 
to the CRT 

from the details, yet at times the two parts must be 
manipulated separately (for instance, to access data in 
an OSP segment knowing only the segment token/base 
value). 

To get around this, these examples assign a pair of word 
variables to the same address as a PL/M pointer vari- 
able. Each representation is then an alias for the other. 
To determine the base or offset value of an item of data, 
load the pointer variable with a pointer to the item and 
then reference the appropriate field of the overlay ed 
pair of word variables. To “build” an arbitrary pointer, 
assign computed values to the base and offset fields and 
then access the data item via the composite pointer. 

Exercise 13: PL/M 86 does not have built-in func- 
tions to separate the high and low-order words of a 
pointer variable. Does this seem to be a weakness 
in the language? Bear in mind that the machine 
representation for pointers varies depending on 
which programming model is specified at compila- 
tion time. When the “small” model is selected, the 
compilers take advantage of a 16-bit pointer 
representation for faster and more compact code. 

Console Command Interpreter 

If a system has a console keyboard, it’s probably used 
to accept and interpret operator commands. For this 
demonstration system, the lowest priority of all tasks is 
a simple-minded routine which polls the US ART until a 
character has been received, and immediately echoes it 
by calling — you guessed it! — PROTECTED 
$CRT$OUTPUT. Thus, the keyboard is “alive”; it 
responds immediately to keystrokes, so the operator 
can type whatever nonsense he desires while every- 
thing else is going on. 

Ten of the keys (digits 0 through 9), invoke special 
commands which illustrate interactions between the 
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multiple tasks. Commands 0 and 1 print out the time 
and status messages; the rest suspend and resume 
various tasks, as shown by Table 2. The code for 
COMMAND$TASK appears in Example 11. 


Initialization Task 

Now that the application tasks have been written, we 
can write the initialization task. 

All applications require a special type of task to initial- 
ize system variables and peripherals and create tasks 
and other objects used by the application. It, too, is 
written as a PL/M procedure, and can thus be divided 
conceptually into the same three phases. 

Example 12 shows such a task for the demonstration 
system. The first thing INIT$TASK does is determine 
the base address of the job data segment by assigning 
pointer DATA$SEG$PTR with its own address. Next it 
calls the RQ$GET$TASK$TOKENS routine, which 
tells the task what token value the OSP assigned it at 
run time. It then initializes the system peripherals by 
creating the hardware initialization task discussed 
above; this code could have been integrated into 
INIT$TASK itself just as easily. During its own 
“execution” phase, INIT$TASK calls routines to 
create the OSP data structures shared by the applica- 
tion tasks: the REGION controlling access to the 
US ART, and the MAILBOX repository for output mes- 
sages. INIT$TASK creates the application tasks them- 
selves by calling RQ$CREATE$TASK. 

Though not always required, it is common practice for 
the overall initialization task to suspend itself after 
creating each offspring, to let the newborn task get 
started. Under this convention, each offspring task 
must resume the initialization task by calling the 


COMMAND*TASK: PROCEDUREi 

DECLARE CONSOLE*CHAR BYTEi 
DECLARE COMMAND*EXCEPT»CODE WORD; 

CALL RQ*RESUME*TASK(INIT*TASK*TOKEN, aCOMMAND»EXCEPT$CODE) i 
DO FOREVER; 

CONSOLE*CHAR=C*IN AND 7FH; 

CALL PROTEC TED*CRT*OUT < CONSOLE*CHAR ) ; 

IF CONSOLE*CHAR=CR 

THEN CALL PROTECTED*CRT*OUT(LF) ; 

IF <CONSOLE*CHAR >= 'O') AND ( CONSOLE*CHAR <» '9') 
THEN DO; 

CALL PROTECTED*CRT*QUT ( CR ) ; 

CALL PROTECTED*CRT*OUT ( LF ) ; 

DO CASE (C0NSOLE*CHAR-'O')i 
CALL PRINT»TOD; 

CALL PRINT*STATUS; 

CALL RQ*SUSPEND*TASK < CRT*OUT»TASK*TOKEN. 

aCOMMAND*EXCEPT*CODE ) ; 

CALL RQ*RESUME*TASK ( CRT«OUT*TASK*TOKEN, 
aCOMMAND*EXCEPT*CDDE ) i 
CALL RQ*DISABLE(AC*INTERRUPT»LEVEL. 

aCOMMAND»EXCEPT*CODE ) ; 

CALL RQ*ENABLE<AC*INTERRUPT$LEVEL. 

aCOMMAND*EXCEPT*CODE ) ; 

CALL RQ*SUSPEND*TASK ( MOTOR*TASK$TOKEN, 
aCOMMAND*EXCEPT*CDDE) ; 

CALL RQ»RESUME*TASK ( MOTOR*TASK*TOKEN. 

aCOMMAND$EXCEPT*CODE ) ; 

CALL RQ*SUSPEND*TASK ( STATUS*TASK*TOKEN; 

aCOMMAND$EXCEPT*CODE ) ; 

CALL RQ*RESUME*TASK ( STATUS*TASK$TOKEN, 
aCOMMAND*EXCEPT$CODE ) ; 

END; /* OF CASE-LIST */ 

END; /* OF COMMAND PROCESSING */ 

END; 

END COMMAND*TASK; 


Example 1 1 . Task to Accept and Process Keyboard 
Commands 

INIT*TASK: PROCEDURE PUBLIC; 

DECLARE INIT$EXCEPT$CODE WORD; 

DATA»SEG*PTR=aiNIT*TASK*TOKEN; /*LOAD DATA SEGMENT BASE*/ 

CRT*MAILBOX$TOKEN=RQ»CREATE$MAILBOX(0. aiNIT$EXCEPT»CODE) ; 

CRT*REGION»TOKEN=RQ»CREATE»REGION(0, eiNIT*EXCEPT*CODE> ; 

I N I T$TASK$TOKEN-RQ*GET*TASK*TOKENS ( 0. a I N I T»EXCEPT$CODE ) ; 

HARDWARE*INIT*TASK*TOKEN=RQ*CREATE*TASK 

(110, aHARDWARE«INIT«TASK, DATA»SEO«ADOR BASE, O, 300, 

0. aiNIT»EXCEPT*CODE>; 

CALL RQ»SUSPEND*TASK(0, aiNIT*EXCEPT*CODE) ; 

STATUS»TASK»TOKEN=R(J*CREATE*TASK (110, aSTATUS*TASK, 
DATA$SEG*ADDR. BASE, 0, 300, 0, aiNIT*EXCEPT*CODE) ; 

CALL RQ$SUSPEND*TASK(0, aiNIT$EXCEPT*CODE) ; 

MOTOR$TASK*TOKEN»RQ*CREATE*TASK( 110, aMOTOR»TASK, 
DATA»SEG$ADDR. BASE, 0, 300, 0, aiNIT$EXCEPT*CODE) ; 

CALL RQ*SUSPEND*TASK(0, eiNIT$EXCEPT»CODE) ; 

TIME»TASK$TOKEN=RQ*CREATE*TASK( 120, eTIME*TASK, 

DATA»SEG*ADDR. BASE, 0, 300, 0, aiNIT*EXCEPT»CODE ) ; 

CALL RQ*SUSPEND*TASK(0, eiNIT»EXCEPT*CODE>; 

CRT»0UT*TASK»T0KEN=RQ*CREATE$TASK( 120, aCRT*OUT*TASK, 
DATA»SEG*ADDR. BASE, 0, 300, 0, eiNlT*EXCEPT*CODE ) ; 

CALL RQSSUSPEND*TASK(0, aiNIT»EXCEPT»CODE) ; 

COMMAND*TASK*TDKEN=RQ»CREATE*TASK( 130, aCOMMAND»TASK, 
DATASSEGSADDR. BASE, 0, 300, 0. eiNIT*EXCEPT»CODE ) ; 

CALL RQ»SUSPEND»TASK(0, GINI T»EXCEPT*CODE ) ; 

CALL RQ*END»INIT*TASK; 

CALL RQ»DELETE*TASK(0, eiNlT*EXCEPT»CODE> ; 

END INIT*TASK; 

Example 12. Task to Initialize System Software 


Table 2. Special Console Commands 


Key 

Function 

0 

Send Time-of-day message to CRT. 

1 

Send status update message to CRT. 

2 

Suspend CRT output task. The OSP will automatically save messages to the task 
in the CRT mailbox queue. 

3 

Resume CRT output task. Queued messages will be displayed. 

4 i 

Disable 60-Hz interrupt-driven time base. Time-of-day clock will stop. 

5 

Enable 60-Hz time base to resume clock execution. 

6 

Suspend motor control task. Motor will stop. 

7 

Resume motor control task. Note that if task was suspended 17 times, it must be 
resumed 17 times. 

8 

Suspend status polling task. Lights indicating system status will freeze in current state. 

9 

Resume status polling task. 
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RQ$RESUME$TASK routine when its own local in- 
itialization is complete. This convention is called 
synchronous initialization; its purpose is to ensure that 
each task is allowed to complete its own start-up phase 
before the next task is created. Otherwise, there’s a risk 
that higher-priority tasks created later could start exe- 
cuting before earlier tasks were ready for them, with (at 
best) unpredicatable results. 

When all the tasks have been created, INIT$TASK has 
served its purpose. It must then call RQ$SEND$ 
INIT$TASK. This short procedure (actually self- 
contained in an OSP Support Package interface library, 
not built into the 80130) tells the OSP that all the off- 
spring tasks have been created for a given job. At this 
point, INIT$TASK could continue with non-initializa- 
tion activities. The code for KEYBOARD$TASK might 
have been implemented here, for example. Since this 
example has nothing more to do, INIT$TASK deletes 
itself with a final call to RQ$DELETE$TASK. 

Code Translation 

That’s all, folks. Mix together the above code frag- 
ments, declare literals and global variables, and com- 
pile until done (about four minutes). The source file 
name selected for this example is AP130.PLM. The 
compiler will produce two files: an annotated source 
listing (named AP130.LST) reproduced in toto in Ap- 
pendix B, and a relocatable object file (AP130.OBJ) 
which will be used in the installation procedure dis- 
cussed next. 


High-Level Parameter Passing 
Conventions 

Well-designed programs generally rely on subprograms 
(“procedures” in PL/M terminology) for often- 
repeated instruction sequences, or to perform 
machine-level operations within High-Level Language 
programs. PL/M-86 and other Intel high-level languages 
use a standard set of conventions to pass parameters 
and results between procedures; assembly language 
programmers are advised to adhere to these conven- 
tions for software compatibility. 

Before calling a subroutine or function, input 
parameters must be pushed sequentially onto the stack, 
in the order (left-to-right) they appear in the procedure 
parameter list. When eight-bit parameters are pushed, 
the high-order byte associated with them is undefined. 
Thirty- two-bit pointer values are pushed in two steps, 
offset word before base word. The stack “grows” 
down, so the left-most parameter will have highest- 
numbered address. 


Functions which return a byte or word value (i.e. , typed 
procedures) do so in the CPU AL or AX registers. 
Pointers are returned through the ES: AX register pair. 
The PLIM Programming Manual explains these con- 
ventions more fully. 

One way to see how an assembly language routine 
would interface with PL/M is to first write a dummy 
PL/M procedure using the same parameter sequence as 
the desired assembly language routine. Compile this 
procedure with the compiler CODE switch set. The 
listing will then include the appropriate assembly lan- 
guage instruction sequence, and may be followed as a 
pattern for the final routine. 

SOFTWARE CONFIGURATIONS & 
INTEGRATION 

When the application code has been written and com- 
piled, the hardest part of program development is over. 
Before the code may be executed, though, the OSP 
must be told various things about the system hardware 
environment, desired software options, application job 
characteristics, and so forth. 

This information is conveyed during a multi-phase se- 
quence of steps collectively called the Configuration 
process. Though the process is somewhat lengthy and 
time-consuming, it is also very “mechanical”; the per- 
son doing the work does not need to understand any of 
the application code or even know what it does. Nor- 
mally, configuration would be performed by a techni- 
cian or a single member of the programming team, aided 
by appropriate SUBMIT command files. This chapter 
shows the full configuration and installation process for 
the demonstration system. For more details, refer to 
the OSP User's Manual. 

The three phases of the configuration are: 

1. Generating, linking, and locating OSP support code 
required for the EPROM immediately above the 
80130 address space; 

2. Linking and locating the object file for the applica- 
tion job developed in Section IV ; 

3. Creating, linking, and locating a short module 
(called the Root Job) which initializes the OSP and 
application jobs when system is reset. 

Finally, of course, the absolute code resulting from each 
phase must be programmed into EPROMs or loaded 
into a test system before it can be executed. 

Before starting, though, it is beneficial to draw up a 
memory map for host system hardware, to determine 
what sections of memory are available. This map will be 
filled in as each module is linked and located. 
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The prototype system memory space has two areas of 
interest: addresses OOOOOH through OIFFFH contain 
RAM, while OFCOOOH through OFFFFFH contain 
EPROM. Since the CPU uses the first IK bytes of RAM 
for the CPU interrupt pointers, and the last 16 bytes for 
the restart sequence, these areas should be recorded on 
the map. For reference purposes. Figure 11 also indi- 
cates that addresses 0F8000H through OFBFFFH 
enable the 80130 firmware. All this is shown in 
Figure 11. 

Generating the OSP Support Code 

The OSP support code “customizes” the OSP firmware 
for a particular hardware environment, initializes the 
system, and supports extended software capabilities. 


To define the hardware environment, the user creates a 
source file which invokes a series of Intel-supplied 
macros. Parameters for these macros specify the 80130 
I/O base address, SYSTICK interval (in system clock 
cycles), and how the interrupt request pins will be used. 

For instance, the code example in Figure 12 defines the 
prototype system hardware. This source file must be 
assembled, linked with several libraries from the OSP 
support disk, and located to produce the actual OSP 
support code. Figure 13 shows the actual sequence of 
commands needed. The DATA starting address speci- 
fied within the LOC86 parameter list (00400H) is the 
first free byte of system RAM (see Figure 11); the 
CODE address (0F8000H) is simply the 80130 firmware 
starting address. 


MEMORY MODULE 


EPROM 

(2x2764) 


RAM < 


STARTING ENDING 
ADDRESS ADDRESS 


8086 RESTART VECTOR 

0FFFF:0 

0FFFF:F 













i 

0FC00:0 





80130 MEMORY SPACE 

0F800:0 

0FBFF;F 






01FF:F 

i 















. 







I 


8086 INTERRUPT VECTOR 

0000:0 

003F:F 


APPLICATION JOB STARTING ADDRESS: - 
ROOT JOB STARTING ADDRESS: 


Figure 11. Example System Memory Map 


$TITLE (80130 DEVICE CONFIGURATION TABLE) 

NAMEODEVCF 

*INCLUDE< : FI ; NDEVCF. MAC) 

7.MASTER_P ICC 80130, 2000H, 0, 0) 

iSLAVE_PIC( SLAVE_TYPE, BASE_PORT, EDGE_VS_LEVEL, MASTER., ..LEVEL ) 
■/.TIMER (80130, 2008H, 2BH, 12500) 

; NDP_SUPPORT( ENCODED_LEVEL ) 

END 


Figure 12. 80130 Device Configuration Table 
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:F0:ASM86 ; FI : SUP 130. A86 PR INT ( : FI : SUP 1 30. LST ) ERRORPRINT ?< 
MACROCBO) PAGEWIDTH< 132) 


,F0;LINi^86 ?< 

: FI. QSX. LIB(0SX86. OSXCNF). 


FI; NUCl, LIB(NBEGIN), 

FI: ODEVCF. OBJ, 

F1:0SX.LIB, 

FI ; NUCl, LIB, fy. 

F1:0SX.LIB, & 

F1.NUC2. LIB, 

FliOSX.LIB, & 

F1:NUC4. LIB, & 

FIOSX.LIB, 8, 

FI; NURSLU. LIB, & 

Fl.OSX.LIB ?/. 


TO ; FI : SUP130. LNK MAP PR INT ( : FI : SUP 130. MP 1 ) NAME < MINIMAL.. 801 30 ) 


: FO; LOG 86 & 

: FI: SUP130. LNK TO ;F1;SUP130 MAP PRINT! ; FI : SUP130. MP2) SCO) & 
SEGSIZE<STACK<0) ) fy 

ADDRESSES < CLASSES (CODE ( 0F8000H ) , DATA ( 00400H ) ) ) & 

ORDER (CLASSES (DATA, STACK) ) 8< 

OBJECTCONTROLS! NOLINES, NOCOMMENTS, NOSYMBOLS) 


Figure 13. Support Code Configuration Commands 


A reliable and relatively straightforward way to per- 
form this step is to create a file containing the exact 
command sequence shown in Figure 13 and execute 
this file using the SUBMIT utility program. Of course, 
the example assumes SUBMIT, ASM86, LINK86, 
and LOC86 are all on drive :F0:, and that the various 
libraries have been copied from the support disk to 
drive :F1:. 

(An alternate, support-code configuration scheme lets 
the user modify the OSP software characteristics in 
special situations. A programmer working with iRMX 
86, for instance, may wish to augment the OSP 
firmware to support all the iRMX Nucleus primitives. 
This would be done by editing and assembling file 
0TABLE.A86 to select from a menu of software op- 
tions, and modifying the linkage step slightly to include 
one of the iRMX 86 libraries. The OSP built-in features 
are more than sufficient for the purposes of this note, 
though, so only the first approach is illustrated.) 

Appendix D reproduces the Locate map file produced 
during this phase. Near the end of file SUP130.MP2 is a 
table of memory usage, showing that the last bytes of 
RAM and ROM consumed are 00A6: FH and 0FC61: 
FH, respectively. Update Figure 11 with this informa- 
tion. (The final version of the demonstration-system 
memory map appears in Appendix C.) This phase 
needn’t be repeated unless the system hardware char- 
acteristics change. 


Application Code Configuration 

After compiling the application job, it must be linked 
with a library of interface routines from the support 
diskette, and located within available memory. Use 
RPIFC.LIB or RPIFL.LIB, depending on whether the 
job was compiled with the Compact or Large software 
model. Figure 14 is a command sequence file suggested 
for this purpose. Again, the starting addresses specified 
for LOC86 are taken from the system memory map. 


Whenever the support code is reconfigured, check 
SUP130.MP2 to see if its memory needs have changed. 
If so, the application-job-configuration command file 
will need to be edited. This is still a lot simpler (not to 
mention more reliable) than retyping the whole se- 
quence each time application jobs are revised. Readers 
familiar with the capabilities of the SUBMIT program 
may prefer to represent these variables by parameters, 
such that they may be easily specified each time the 
command file is invoked. 


As in the first phase, examine the locate map 
(“AP130.MP2”, reproduced in Appendix E) after the 
application code has been configured and update the 
memory map. Also, note the segment and offset values 
assigned to the initialization task. These will be needed 
later. 
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Creating the Root Job 

By now, all of the code needed to execute the applica- 
tion program has been prepared and is ready to run 
— except it has no way to get it started! The OSP hard- 
ware and system data structures must be initialized 
before INIT$TASK can be created. A short module 
called the Root Job performs this function. 

The process closely resembles the one which produced 
the OSP support code. First, determine various system 
characteristics. Then create a file defining these charac- 
teristics as macro input parameters. Finally, assemble, 
link, and locate the file to produce the final code. 


Figure 15 is the Root Job source file for the demonstra- 
tion system, dubbed RJB 130. A86. It consists of just five 
macro calls. The %JOB macro defines certain charac- 
teristics of the application job; for a full description see 
the OSP User’s Manual. One of these parameters is the 
initialization-task starting address (noted in the last 
step), which will likely change with each iteration of the 
application software. 

The two %SAB macros define “System Address 
Blocks” — sections of the overall memory space which 
the OSP should not consider “free space.” Note that 
the first invocation blocks off the RAM addresses con- 
sumed so far in the memory map, plus an extra 140H 
bytes reserved for the Root Job initialization stack. 


SUBMIT FILE TO LINK APPLICATION JOB TO INTERFACE LIBRARY 
AND LOCATE RESULTING OUTPUT. 

REVISED 10/23/81 - JHW 


LINK86 : FI: AP130. OBJ, : FI : RPIFC. LIB TO : FI : AP 130. LNK ?< 

MAP PRINT<: FI: AP130. MPl) 

L0C86 . FI: AP 130. LNK TO :F1:AP130 S< 

ORDER (CLASSES<DATA, STACK, MEMORY) ) & 

SEGSIZE (STACK (0)> & 

ADDRESSES (CLASSES (DATA (00A70H), 

CODE (0FC620H))) 

MAP PRINT (: FI: AP130. MP2) 


OBJECTCONTROLS (NOLINES, NOCOMMENTS, NOPUBLICS, NOSYMBOLS) 
0HS6 :F1:AP130 TO : FI : AP130. H86 
COPY : FI; AP130. MPl TO :LP: 

COPY : FI : AP130. MP2 TO : LP: 


Figure 14. Job Configuration Commands 


; SOURCE PROGRAM DEFINING CHARACTERISTICS OF ROOT JOB FOR 
;AP-130 DEMONSTRATION PROGRAM (JHW - 10/25/81) 

»INCLUDE(: FI: CTABLE. MAC) 

7.SAB(0, OOCO, U) 

%SAB(0200, FFFF, U) 

7.J0B(0, OCOH- lOOH, OFFFFH, OFFFFH, 1, 0: 0, 1, 0, 100, 0FC62: 06B5, 0, 0: 0, 200H, O) 
■/.OSX ( 0F8000H, N ) 

•/.SYSTEM (F800, 0, 4, N, N, 1 ) 

END 


Figure 15. Root Job Configuration File 
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(After completing this phase, examine RJB130.MP2 to 
confirm that 140H is the correct number.) The second 
%SAB invocation excludes addresses 02000H through 
OFFFFFH, all of which is non-RAM, either EPROM, 
80130 firmware, or non-existent. The %SYSTEM 
macro defines system- wide software parameters. 

Figure 16 is a command file to translate, link, and locate 
the root job. Once again, the LOC86 parameters come 
from Figure 1 1 . The listings produced during this phase 
are reproduced in Appendix F. The final memory map 
appears in Appendix C. 


EPROM Programming 

We are now ready to program EPROMs with the pro- 
gram modules linked and located above. Intel’s Univer- 
sal PROM Programmer (UPP) and a control program 
called the Universal Prom Mapper (UPM) will be used 
in this step. Particular commands to the UPM will vary 
with program size, memory location, and EPROM type, 
but the general sequence should resemble that shown 
here. 

The first step is to invoke UPM and initialize the pro- 
gramming system, following a command sequence 
similar to that in Figure 17. The example system incor- 
porates two 2764 devices, so 16K bytes of memory 
buffer are cleared. 

Next, all the final code modules produced above (e.g., 
SUP 130, API 30, and RJB130) must be loaded into the 


UPM memory buffer. The three commands in Figure 18 
perform this function. 

When the final system is reset, execution must branch 
into the root job initialization sequence. When the abso- 
lute code modules have finished loading, manually 
patch a jump instruction into the buffer area corres- 
ponding to the GPU reset vector. The opcode for the 
8086 or 8088 intersegment jump is OEAH; the instruc- 
tion’s address field must contain the address assigned to 
label RQ$START$ ADDRESS (read from the root job 
locate map), the 16-bit segment offset (low byte first) 
followed by the segment base address (ditto). The UPM 
CHANGE command should be used to make this 
patch, as illustrated in Figure 19. 

The UPM memory buffer now contains a complete 
image of the code needed for the system EPROMs. Up 
until now, all software-related steps — source code 
preparation, translation, linking and locating — have 
been the same for 8086- or 8088-based systems. At this 
point, however, the software installation procedures 
diverge slightly. 

Recall that the 8086 fetches instructions 16 bits at a 
time, from coordinated pairs of EPROMs. One contains 
only even-numbered program bytes, the other, odd. To 
separate the linear UPM buffer into high- and low-order 
bytes for iAPX 86/30 designs, use the UPM STRIP 
command as shown in Figure 20. 

Now “burn” the EPROMs with the PROGRAM com- 
mand in Figure 21. 


; LINK AND LOCATE THE iRMX 86 

ROOT JOB. 


i MODIFIED FOR TWO-DRIVE OPERATION 


i REVISED 10/25 - JHW 



ASMS6 : f 1: RJB130. A86 MACRO (75) 



LINK86 



. fl; croot. lib(root), 



; f 1: RJB130. ob j> 

tc 


; f 1; croot. lib 

& 


TO : f 1: RJD130. Ink 

MAP PRINT( . f 1: RJB130. mpl ) 



L0C86 : f 1: RJB130. Ink 

& 


TO :F1:RJB130 



MAP PRINT( : fl; RJB130. mp2) 

?< 


OC(noli. nopl> nocm. nosb) 

tu 


PC(noli. pi. nocm. nosb) 

& 


SEGSIZE(stack(0) ) 



ORDER ( c lasses < data, stack. 

memory ) ) 


ADDRESSES <classes(code< OFD 1 80H ) , 


data(OOADOH) ) ) 


0H86 :F1:RJB130 TO ; Fl ; R JB130. H86 


COPY ; Fl : RVB130. LST TO : LP ; 



COPY : Fl: RJB130, MPl TO ;LP; 



COPY : Fl: RJB130. MP2 TO :LP: 




Figure 16. Root Job Configuration Commands 
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fill from 0 to 3fffh with Offh 


Figure 17. UPM Initialization Sequence 


read 86hex file : f1 : eup130. h86 from 0 to 3fffh start OfcOOOh 
read 86hex file : f1 : ap130. h86 from 0 to 3fffh start OfcOOOh 
read 86hex file : f1 : rjb130. h86 from 0 to 3fffh start OfcOOOh 


Figure 18. UPM Commands to Load Hex Files 



program from 4000h to Sfffh start 0 

program from 6000h to 7fffh start 0 
exit 

Figure 21. UPM Commands to Program EPROMs 


To save some trouble, the UPM invocation and all com- 
mands except the manual patch can be combined into a 
SUBMIT command file. Replace the CHANGE com- 
mand with a control-E character so the operator can 
adjust the starting address for the iteration. Also place 
control-Es before each PROGRAM step to give the 
operator time to socket the next memory device. 

SUMMARY 

The development of the 80130 marks a major milestone 
in the evolution of microcomputer systems. For the 
first time, a single VLSI device integrates the hardware 
facilities and operating system firmware needed by 
real-time multitasking applications. The 80130 offers 
the system hardware designer the advantages of higher 
integration — reduced device count, smaller boards, 
greater reliability — along with faster design cycles and 
optimal system performance. 

The 80130 gives the software engineer built-in support 
for 35 standard operating system primitives. Applica- 
tion problems may now be solved at a higher level than 


before. It is now possible for concurrent tasks to be 
dispatched, memory segments allocated, and messages 
relayed through mailboxes nearly as easily as sub- 
routines, dynamic variables, and I/O ports were used in 
the past. In effect. Jobs, Tasks, Segments, Mailboxes, 
and Regions become new OSP data types, manipulated 
entirely by firmware in the 80130, 

Yet despite standardizing these functions, the OSP does 
not restrict the user’s flexibility. The device can accom- 
modate a variety of hardware environments, and both 
the hardware and software capabilities are desired. 
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APPENDIX A 
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Figure A-1. Example System Schematics 
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Figure A-1. Example System Schematics (continued) 
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ISIS-Il PL/M-S6 V2. 0 COMPILATION OF MODULE DEM0130 
OBJECT MODULE PLACED IN : FI ; AP 130. OB J 

COMPILER INVOKED BY: PLMS6 : FI : AP 130. PLM DATE( 12/21) 


HiDEBUG COMPACT ROM TITLE< 'AP-130 APPENDIX B - 12/21/81') 

1 DEM0$130: DO; 

/* SYSTEM-WIDE LITERAL DECLARATIONS: •»/ 

2 1 DECLARE FOREVER LITERALLY 'WHILE OlH'; 

/* I/O PORT DEFINITIONS: ■«•/ 

3 1 DECLARE CHAR$51 LITERALLY '4000H', 

CMD^Sl LITERALLY '4002H'. 

STATifiSl LITERALLY '4002H'; 

4 1 DECLARE PPI^A LITERALLY '600 IH', 

PPI$B LITERALLY '6003H', 

PPI^C LITERALLY '6005H'. 

PPI^CMD LITERALLY '6007H', 

PPI^STAT LITERALLY '6007H'; 

5 1 DECLARE TIMER^CMD LITERALLY '200EH', 

BAUD^TIMER LITERALLY '200CH'; 

6 1 DECLARE AC$I NTERRUPT^-EVEL LITERALLY 'OOlllOOOB'; 

7 1 DECLARE CR LITERALLY 'ODH', 

LF LITERALLY 'OAH', 

BEL LITERALLY '07H'; 

8 1 DECLARE ASCII^CODE (16) BYTE DATA ( '0123456789ABCDEF ' ) ; 


REJECT 

^INCLUDE { ; FI: NUCLUS. EXT) 

= ^BAVE NOLIST 

^INCLUDE ( . FI : NEXCEP. LIT) 

= ^save nolist 

/* GLOBAL VARIABLE DECLARATIONS: */ 

299 1 DECLARE DATA^SEG^PTR POINTER, 

DATA$SEG$ADDR STRUCTURE (OFFSET WORD, BASE WORD) 
AT (@DATA$SEG$PTR); 

300 1 DECLARE HARDWAREifcINIT$TASK$TOKEN WORD, 

STATUS$TASK$TOKEN WORD, 

MOTOR^TASK$TOKEN WORD, 

TIME$TASK$TOKEN WORD, 

AC^HANDLER^TOKEN WORD, 

CRT$OUT$TASKitTOKEN WORD, 

COMMAND$TASK$TOKEN WORD, 

INIT^TASK$TGKEN WORD; 

301 1 DECLARE CRT$MAILBOX$TOKEN WORD, 

CRT$REGION$TOKEN WORD; 
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REJECT 

/* CODE EXAMPLE 2. SIMPLE CRT INPUT AND OUTPUT ROUTINES. */ 

302 1 C^OUT: PROCEDURE (CHAR); 

303 2 DECLARE CHAR BYTE; 

304 2 DO WHILE (INPUT ( STAT^Sl ) AND 01H)==:0; 

/•«• NOTHING »/ 
aOO 3 END; 

306 2 0UTPUT(CHAR$51)=CHAR; 

307 2 END C^OUT; 

CitIN; PROCEDURE BYTE; 

DO WHILE ( INPUT (STAT$51 ) AND 02H)=0; 

/* NOTHING */ 

END; 

RETURN INPUT ( CHAR$51 ); 

END ClilN; 


REJECT 

/•«- CODE EXAMPLE 1. HARDWARE INITIALIZATION TASK. ■»•/ 

313 1 HARDWARE^INIT^TASK: PROCEDURE; 

314 2 DECLARE HARD$INIT$EXCEPT$CODE WORD; 

315 2 DECLARE PARAM$51 < «• ) BYTE DATA ( 40H, 8DH> OOH, 40H, 4EH, 27H ) ; 

316 2 DECLARE PARAM$51*INDEX BYTE; 

317 2 DECLARE SIGN^ON^MESSAGE (*) BYTE DATA 

(CR>LF3 'iAPX 86/30 HARDWARE INITI ALI ZED ^ CR, LF ) ; 

318 2 DECLARE SIGN$ON$INDEX BYTE; 

319 2 OUTPUT (PP I $CMD)=90H; 

320 2 OUTPUT (TIMER$CMD)=0B6H; 

321 2 OUTPUT (BAUDOT I MER ) =33; /^GENERATES 9600 BAUD FROM 5 MHZ*/ 

322 2 OUTPUT ( BAUD^TIMER )=0; 

323 2 DO PARAM$51SINDEX=0 TO < SI ZE ( PARAMOS 1 )~ 1 ) ; 

324 3 OUTPUT ( CMD^Sl )=PARAM$51 (PARAM$51$INDEX>; 

’-'b 3 END; /*0F USART INITIALIZATION DO-LOOP*/ 

26 2 DO SIGN$0N$INDEX=0 TO (SI ZE (SIGN^0N$MESSAGE)-1 ) ; 

27 3 CALL Ci$OUT(SIGN$ON»MESSAGE(SIGN$ON$INDEX) ); 

328 3 END; /*0F SIGN-ON DO-LOOP*/ 

329 2 CALL RQ^$RESUME$TASK ( INIT$TASK$TOKEN, @HARD$INIT$EXCEPT^CODE ) ; 

330 2 CALL RQ$DELETE^TASK(0, @HARD$INIT«EXCEPT^CODE); 

331 2 END HARDWARES INIT^TASK; 


REJECT 

/* CODE EXAMPLE 3. STATUS POLLING AND REPORTING TASK. */ 


332 1 STATUS^TASK; PROCEDURE; 

333 2 DECLARE STATUS^COUNTER BYTE; 

334 2 DECLARE STATUS^EXCEPT^CODE WORD; 

STATU9^C0UNTER=0; 

CALL RQi^RESUME^TASK( INIT^TASK^TOKEN, @STATUS$EXCEPT$CODE ) ; 
DO FOREVER; 

OUTPUT ( PP I^B )=INPUT(PPI$A) XOR STATUS^COUNTER; 
STATUS$cbuNTER=STATUS^COUNTER+l; 

CALL RQ$SLEEP ( 100; @STATUS$EXCEPT$CODE ) ; 

END; 

END STATUS^TASK; 



30S 1 

309 2 

310 3 

3 1 1 2 

312 2 
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REJECT 


343 1 


344 1 

345 2 

346 2 

347 2 


348 2 

349 2 

350 2 

351 2 

352 2 

353 2 

354 3 

355 4 

356 4 

357 4 

358 4 

359 3 

360 3 

361 4 

362 4 

363 4 

364 4 

365 3 

366 3 

367 2 


368 1 

369 1 

370 2 

37 1 2 

372 2 

373 2 

3 75 3 

376 3 

377 3 

378 2 


379 2 


/* CODE EXAMPLE 4. STEPPER MOTOR CONTROL TASK. «/ 

DECLARE CW$STEP^DELAY BYTE/ 

CCW$STEPi^DELAY BYTE, 

CW»PAUSE$DELAY BYTE, 

CCW$PAUSE$DELAY BYTE; 

MOTORi^TASK; PROCEDURE; 

DECLARE MOTOR$EXCEPT$CODE WORD; 

DECLARE MOTOR^POSITION BYTE, 

MOTORitPHASE BYTE; 

DECLARE PHASE$CODE (4) BYTE 

DATA < 00000 lOlB, 000001 lOB, OOOOlOlOB, OOOOIOOIB); 

CW»STEP$DELAY=50; /^INITIAL STEP DELAYS « 1/4 SECOND*/ 
CCW$STEP^DELAY=50; 

CW«PAUSE^DELAY=200; /^PAUSES AFTER ROTATION = 1 SECQND-J^/ 
CCW^PAUSE«DELAY=200; 

CALL RQ$RESUME$TASK< INIT$TASK$TOKEN, @MOTOR«EXCEPT$CODE); 

DO FOREVER; 

DO M0T0R$P0SITI0N=^0 TO 100; 

MOTOR$PHASE=MOTOR$POSITION AND 0003H; 

OUTPUT ( PP I $C ) «PHASE$CODE ( MOTOR$PHASE ) ; 

CALL RQSSLEEP(CW«STEP$DELAY, ®MOTOR$EXCEPT$CODE ) ; 
END; 

CALL RQ^SLEEP < CW$PAUSE^DELAY, @MOTOR$EXCEPT$CODE ) ; 

DO M0T0R^P0SITI0N=0 TO 100; 

MOTOR$PHASE=< 100“M0T0R$P0SITI0N) AND 0003H; 

OUTPUT ( PP I ^C) =PHASE«CODE < MOTOR^PHASE ) ; 

CALL RQ^SLEEP ( CCW^STEP^DELAY, @MOTOR$EXCEPT$CODE ) ; 
END; 

CALL RQ^SLEEP ( CCW^PAUSE^DELAY, SMOTOR^EXCEPT^CODE ) ; 

END; 

END MOTOR^TASK; 


$EvJECT 

/* CODE EXAMPLE 5. INTERRUPT HANDLER TO TRACK 60 HZ INPUT. */ 
DECLARE AC$CYCLE*COUNT BYTE; 

AC^HANDLER; PROCEDURE INTERRUPT 59; /^VECTOR FOR 80130 INT3*/ 
DECLARE ACi^EXCEPT^CODE WORD; 

CALL RQ$ENTER*INTERRUPT(AC$INTERRUPT*LEUEL, @AC$EXCEPT$CODE > ; 
AC$CYCLE$C0UNT==AC$CYCLE$C0UNT+1; 

IF AC$CYCLE$COUNT >= 60 
THEN DO; 

AC$CYCLE$C0UNT=-0; 

CALL RQ*SIQNAL*INTERRUPT<AC$INTERRUPT$LEVEL, 
SAC^EXCEPT^CODE); 

END; 

ELSE CALL RQ$EX IT^INTERRUPT ( AC^INTERRUPT^LEVEL, 
@AC$EXCEPT«CODE); 

END ACi^HANDLER; 
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4iEJECT 


380 1 

381 2 

382 2 

383 2 

384 2 

38 S 3 

386 2 

387 2 

388 2 


/* CODE EXAMPLE 7. PROTECTED CRT OUTPUT SUBROUTINE. 

PROTECTED^CRT^OUT; PROCEDURE <CMAR) REENTRANT; 

DECLARE CHAR BYTE; 

DECLARE CRT»EXCEPT«GODE WORD; 

CALL RQ«RECElUE*CONTROL<CRT*REOtON*TOKEN> ®CRT*EXCEPT*CODE ) ; 
DO WHILE (INPUT<STAT»S1) AND 01H>««>0; 

/•» NOTHING */ 

END; 

OUTPUT < CHARTS 1 )«i*CHAR; 

CALL RQ$SEND*CONTROL < GCRT*EXCEPT$CODE ) ; 

END PROTECTED$CRT4iOUT; 


«ExJECT 

/•«• CODE EXAMPLE 6. INTERRUPT TASK TO MONITOR CLOCK TIME. »/ 

389 1 DECLARE SECOND$COUNT BYTE. 

MINUTE^COUNT BYTE. 

HOUR^COUNT BYTE; 

390 1 TIM£$TASK: PROCEDURE; 

391 2 DECLARE T IME^EXCEPT^CODE WORD; 


392 2 

393 2 


394 2 

395 2 

396 3 

397 4 

398 5 

399 5 

401 5 

402 4 

403 3 

404 2 

405 2 

406 2 


AC1iCYCLE$C0UNT^0; 

CALL RQ*SET»INTERRUPT<AC#lNTERRUPTSLEVfeL. OlH. 

INTERRUPT$PTR<AC$HANDLER) . DATASSEGfADDR. BASE. 
^TlME<frEXCEPT$COpE)^ 

CALL RQ^RESUME«TASK(lNITtTASKiTOKEN. lME*£XCEPT«CObE) i 
DO H0URiC0UNT*0 TO 23; 

DO MINUTE$COUNTi*D TO S9; 

DO SEC0ND^C0UNT«O TO 59; 

CALL RG$WA 1 1 NtERRUPT ( ACii 1 NTERRUP t^LEUEL. 

®T I ME»E)(CEPT»CODE > ; 

IP SEC0ND«CdUNT MOD 6^6 

THEN CALL PROTECTED$CRT$OUT(BEL); 

END; /* SECOND LOOP */ 

END; /* MINUTE LOOP */ 

END; /* HOUR LOOP 

CALL RQ»RE8ET*INTERRUPT<AC«1NTERRUPT*LEUEL. 
^TlMEiEXCEPT*CODEh 

CALL RQ*DELETE$TASK(0. aTIMESEXCEPT»CODE > > 

END TlME^tASK; 
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REJECT 

/« CODE EXAMPLE 8. SUBROUTINE TO CREATE TIME-OF-DAY MESSAGE. */ 


407 1 

408 2 

409 2 

410 2 

4 1 1 2 

412 2 

4 1 3 2 

414 2 


PRINT$TOD; PROCEDURE; 

DECLARE TOD$MESSAGE$TOKEN WORD; 

DECLARE TOD^EXCEPT^CODE WORD; 

DECLARE TOD$SEGMENT»OFFSET WORD, 

TOD$SEGMENT«BASE WORD; 

DECLARE TOD$SEGMENT*PNTR POINTER AT (@TOD»SEGMENT*OFFSET) ; 
DECLARE TOD$TEMPLATE (28) BYTE 

DATA (27, 'THE TIME IS NOW hh:mm:ss. ',CR,LF); 

DECLARE TOD^STRING BASED TOD^SEGMENT^PNTR (28) BYTE; 
DECLARE TOD$STRING$INDEX BYTE; 


415 2 

4 1 6 2 

4 1 '7 2 

418 2 

419 3 

420 3 

421 2 

422 2 

423 2 

424 2 

425 2 

426 2 

427 2 

428 2 

429 2 


TOD^MESSAGE$TOKEN«RQitCREATE«SEGMENT ( 28, GTOD^EXCEPT^CODE ) ; 
TOD$SEGMENT$BASE*=TOD$MESSAGE$TOKEN; 

T0D^SEGMENT$0FFSET=0; 

DO T0D«STRING$INDEX*0 TO 27; 

TOD^STR I NG ( TOD$STR I NG^ I NDE X ) = 

TOD«TEMPLATE ( TOD^STR I NG* I NDEX ) ; 

END; 

TOD*STR I NG ( 1 7 ) =ASC 1 1 *CODE ( HOUR*COUNT/ 10); 

TOD*STRING( 18)*ASCII*C0DE(H0UR*C0UNT MOD 10); 

TOD*STR I NG ( 20 ) =ASC 1 1 *CODE ( M I NUTE*COUNT/ 10); 

T0D*STRING(21 )=ASCII*CODE(MINUTE*COUNT MOD 10); 

TOD*STR I NG ( 23 ) =ASC 1 1 *CODE ( SECOND*COUNT/ 10); 
T0D*STRING(24)=ASCII*C0DE(SEC0ND*C0UNT MOD 10); 

CALL RQ*SEND*MESSAGE ( CRT*MAILBOX*TOKEN, 

TOD*MESSAGE*TOKEN, 0, @TOD*EXCEPT*CODE ) ; 

RETURN; 

END PRINT*TOD; 


REJECT 

/« CODE EXAMPLE 9. SUBROUTINE TO CREATE SWITCH STATUS MESSAGE. */ 


430 1 

431 2 

432 2 

433 2 

434 2 

435 2 

436 2 

437 2 

438 2 


PRINT*STATUS; PROCEDURE; 

DECLARE STATUS*MESSAGE*TOKEN WORD; 

DECLARE STATUS*EXCEPT*CODE WORD; 

DECLARE STATUS*SEGMENT$OFFSET WORD, 

STATUS*SEGMENT*BASE WORD; 

DECLARE STATUS*SEGMENT*PNTR POINTER 
AT (GSTATUS$SEGMENT*OFFSET); 

DECLARE STATUS*TEMPLATE (40) BYTE DATA 

(39, 'THE SWITCHES ARE NOW SET TO B',CR,LF); 

DECLARE STATUS*STRING BASED STATUS*SEGMENT*PNTR (40) BYTE; 
DECLARE STATUS*STRING*INDEX BYTE; 

DECLARE BIT*PATTERN BYTE; 


439 2 

440 2 

441 2 

442 2 

443 3 

444 3 

445 2 

446 2 

447 3 

448 3 

449 3 

450 2 

451 2 


STATUS*MESSAGE*TOKEN=RQ$CREATE*SEGMENT ( 40, 
@STATUS*EXCEPT*CODE) ; 
STATUS*SEGMENT*BASE=STATUS*MESSAGE*TOKEN; 
STATUS*SEGMENT*OFFSET=0; 

DO STATUS*STRING*INDEX=0 TO 39; 

STATUS*STR I NG ( STATUS*STR I NG* I NDEX ) * 

STATUS*TEMPLATE ( STATUS*STR ING*INDEX ) ; 

END; 

B IT*PATTERN=INPUT (PP I*A ) ; 

DO STATUS*STRING*INDEX==29 TO 36; 

STATUS*STR I NG ( STATUS*STR I NG* I NDEX ) = 
ASCII*CODE(BIT*PATTERN AND OlH); 
BIT*PATTERN*ROR(BIT*PATTERN, 1); 

END; 

CALL RQ*SEND*MESSAGE ( CRT*MAI LBOX*TOKEN, 

STATUS*MESSAGE*TOKEN, 0, @STATUS*EXCEPT*CODE ) ; 
END PRINT*STATUS; 
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REJECT 

/•>^ CODE EXAMPLE 10. TASK TO RECEIVE MESSAGES AND TRANSMIT THEM TO CRT. •«•/ 


1 CRTIiOUT^TASK; PROCEDURE; 

453 2 DECLARE MESSAGE^LENGTH BYTE; 

454 2 DECLARE MESSAGE$TOKEN WORD; 

455 2 DECLARE RESPONSE^TOKEN WORD; 

456 2 DECLARE MESSAGE$EXCEPT«CODE WORD; 

457 2 DECLARE MESSAGE^SEOMENT^OFFSET WORD. 

MESSAGE$SEGMENT$BASE WORD; 

458 2 DECLARE MESSAGE^SEGMENT^PNTR POINTER AT ( @MESSAGE»SEGMENT*OFFSET ) ; 

459 2 DECLARE MESSAGE^STR ING^CHAR BASED MESSAGE*SEGMENT«PNTR BYTE; 


460 2 

46 1 2 

462 3 

463 3 

4 6 4 2 

465 3 

466 3 

467 4 

468 4 

469 3 

470 3 

471 2 


CALL RQ$RESUME$TASK(INIT$TASK«TOKEN, @MESSAGE*EXCEPT$CODE ) ; 

DO FOREVER; 

MESSAGE$TOKEN=RQ$RECEIVE«MESSAGE(CRT^MAILBOX$TOKEN, OFFFFH, 
ClRESPONSE^TOKEN, @MESSAGE«EXCEPT«CODE ) ; 
MESSAGE^SEGMENT$OFFSET=0; 
MESSAGE^SEOMENT$BASE=MESSAGE»TOKEN; 
MESSAGE$LENGTH=MESSAGE$STRING$CHAR; 

DO MESSAGE»SEGMENT«0FFSET=:1 TO MESSAGE^LENGTH; 

CALL PROTECTED^CRT^OUT ( MESSAGE^STR I NG^CHAR ) ; 

END; 

CALL RQ^DELETE$SEGMENT(MESSAGE$TOKEN. @MESSAGE«EXCEPT«CODE ) ; 
END; /•« OF FOREVER-LOOP •»•/ 

END CRT^OUT$TASK; 


REJECT 


CODE EXAMPLE 11. TASK TO POLL KEYBOARD AND PROCESS COMMANDS. •«•/ 


472 1 COMMAND^TASK; PROCEDURE; 

473 2 DECLARE CONSOLE^CHAR BYTE; 

474 2 DECLARE COMMAND^EXCEPT^CODE WORD; 


475 2 

476 2 

477 3 

478 3 

479 3 

431 3 

483 4 

484 4 

485 4 

486 5 

487 5 

48B 5 

489 5 

490 5 

491 5 

492 5 

493 5 

494 5 

495 5 

496 5 

497 4 

498 3 

409 2 


CALL RQ$RESUME$TASK( INIT^TASK^TOKEN, eCOMMAND$EXCEPT«CODE ) ; 
DO FOREVER; 

COWSOLE^CHAR=C$IN AND 7FH; 

CALL PROTECTEDttCRT^OUT ( CONSOLE^CHAR ) ; 

IF CONSOLE^CHAR-CR 

THEN CALL PROTECTED$CRT$OUT ( LF ) ; 

IF (CONSOLE^CHAR >= '0') AND < CONSOLE$CHAR •=:> '9') 
THEN DO; 

CALL PROTECTED$CRT^OUT<CR); 

CALL PROTECTED$CRT*OUT(LF); 

DO CASE (CONSOLE^CHAR- '0 ' ); 

CALL PRINT^TOD; 

CALL PRINT^STATUS; 

CALL RQ$SUSPEND^TASK ( CRT*OUT*TASK$TOKEN. 

@COMMAND$EXCEPT*CODE ) ; 

CALL RQ^RESUME^TASK ( CRT$OUT$TASK«TOKEN. 

@COMMAND*EXCEPT^CODE) ; 

CALL RQ$DISABLE(AC$INTERRUPT^LEVEL. 

@COMMAND$EXCEPT$CODE ) ; 

CALL RQ^ENABLE ( AC^INTERRUPT^LEVEL. 

eCOMMAND^EXCEPT^CODE ) ; 

CALL RQ$SUSPEND^TASK ( MOTOR$TASK$TOKEN, 
@COMMAND*EXCEPT»CODE ) ; 

CALL RQ$RESUME$TASK ( MOTOR$TASK$TOKEN, 
@COMMAND^EXCEPT$CODE ) ; 

CALL RQ«SUSPEND$TASK ( STATUS$TASK$TOKEN, 
eCOMMAND^EXCEPT^CODE ) ; 

CALL RQ^RESUME^TASK ( STATUS^TASK^TOKEN, 
@COMMAND$EXCEPT$CODE ) ; 

END; /* OF CASE-LIST */ 

END; /* OF COMMAND PROCESSING */ 

END; 

END COMMAND$TASK; 
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REJECT 

/* CODE EXAMPLE 12. TASK TO INITIALIZE OSP SOFTWARE. */ 

500 1 INIT$TASK: PROCEDURE PUBLIC,- 

501 2 DECLARE INIT$EXCEPT$CODE WORD; 


502 2 

503 2 

504 2 

505 2 

506 2 


507 2 

soa 2 

509 2 

5 1 0 2 

51 1 2 

512 2 

513 2 

514 2 

515 2 

516 2 

517 2 

518 2 

519 2 

520 2 


DATA$SEO$PTR=@INIT«TASK$TOKEN; /*LOAD DATA SEGMENT BASE*/ 

CRT$MAILB0X$T0KEN=RQ$CREATE»MAILB0X(0, @INIT$EXCEPT$CODE) ; 

CRT*RE0I0N$T0KENssRQ^CREATE^REGI0N(0, ®INIT^EXCEPT*CODE ) ; 

INIT$TASK$T0KEN?sRQ$GET«TASK$T0KENS<0, ®INIT$EXCEPT$C0DE); 

HARDWARE5ilNIT$TASK«T0KEN«RQ«CREATE«TASK 

( 1 10, @HARDWARE$INIT$TASK, DATA$SEG$ADDR. BASE, 0, 300, 

0, @INIT^EXCEPT«CODE); 

CALL RQ^SUSPEND$TASK(0, ^INIT^EXCEPT$CODE) ; 

STATUS$TASK$T0KEN«RQ$CREATE$TASK (110, @STATUS$TASK, 
DATA$SEG*ADDR. base, 0, 300, 0, eiNIT*EXCEPT$CODE)i 

CALL RQ$SUSPEND$TASK(0, @INIT$EXCEPT$CODE ) ; 

M0T0R$TASK«T0KEN*RQ«CREATE^TASK( 1 10, ©MOTOR^TASK, 

DATA$SEG*ADDR. BASE, 0, 300, 0, @INIT«EXCEPT$CODE ) ; 

CALL RQ<tSUSPEND$TASK(0, @INI T$EXCEPT*CODE ) ; 

TIME$TASK«T0KEN==RQ$CREATE$TASK < 120, @TlME$TASK, 

DATA$SEG^ADDR. BASE, 0, 300, 0, @INIT«EXCEPT«CODE ) ; 

CALL R(3^SUSPEND*TASK(0, @1NI T^EXCEPT^CODE ) ; 

CRT*0UT$TASK«T0KEN~R(S«CREATE*TASK( 120, @CRT*OUT»TASK, 
DATA^SEGSADDR. base, O, 300, 0, @INIT$EXCEPT$C0DE); 

CALL RQ^SUSPEND$TASK(0, @INI T$EXCEPT$C0DE ) ; 

COMMAND«TASK^TOKEN~RQ$CREATE$TASK( 130, @COMMAND$TASK, 
DATA$SEG$ADDR. BASE, 0, 300, 0, @INIT«EXCEPT$caDE > ; 

CALL RQ$SUSPEND^TASK(0, <aiNIT^EXCEPT$CODE); 

CALL RQ^END*INIT$TASK; 

CALL RQifcDELETE^TASK(0, @INIT$EXCEPT$C0DE); 

END INIT^TASK; 


521 1 END DEM0$130; 


MODULE INFORMATION: 

CODE AREA SIZE =« 084CH 2124D 

CONSTANT AREA SIZE =*= OOOOH OD 

VARIABLE AREA SIZE « 0052H 82D 

MAXIMUM STACK SIZE « 0026H 38D 

848 LINES READ 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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APPENDIX C 
SYSTEM MEMORY MAP 
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EXAMPLE SYSTEM MEMORY MAP 


STARTING ENDING 
ADDRESS ADDRESS 


EPROM 

(2x2764) 


RAM < 


MEMORY MODULE 


8086 RESTART VECTOR 

0FFFF:0 

0FFFF:F 

ROOT JOB CODE AREA 

0FD18:0 

0FD36:6 




APPLICATION JOB CODE AREA 

0FC62:0 

0FD17:B 




OSP SUPPORT CODE AREA 

0FC00:0 

0FC61:F 




80130 MEMORY SPACE 

0F800:0 

0FBFF:F 




(FREE SYSTEM RAM) 

00C0:0 

01FF-.F 







ROOT JOB DATA AREA 

00AD:0 

00BF:F 


. 


APPLICATION JOB DATA AREA 

00A7:0 

00AC:1 




OSP SUPPORT DATA AREA 

0040:0 

00A6:F 




8086 INTERRUPT VECTOR 

0000:0 

003F:F 


INITIALIZATION TASK STARTING ADDRESS: FC62:06B5 

ROOT JOB STARTING ADDRESS: FD1 8:0011 
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SUPPORT CODE LOCATE MAP 
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ISIS-II MCS-S6 LOCATER, VI. 3 INVOKED BY 
:F0;LQC86 & 

: FI t SUP130. LNK TO :F1; SUP130 MAP PR I NT ( : F 1 : SUP 1 30. MP2 ) SC ( 3 ) S/ 
SEGSI ZE< STACK ( 0) ) 

ADDRESSES (CLASSES! CODE (OF8000H), DATA(00400H) ) ) «•: 

ORDER ( CLASSES < DATA> STACK ) ) 

OBJECTCONTROLS( NOLINES, NOCOMMENTS, NOSYM0OLS) 

WARNING 26: DECREASING SIZE OF SEGMENT 

SEGMENT; STACK 

SYMBOL TABLE OF MODULE MINIMAL_80130 
READ FROM FILE : FI . SUP 130. LNK 
WRITTEN TO FILE :F1:SUP130 


BASE 

OFFSET 

TYPE SYMBOL 

BASE 

OFFSET 

TYPE 

: SYMBOL 

BASE 

OFFSET 

TYPE 

: SYMBOL 

0040H 

OOOOH 

PUB 

INTERRUPTTASKVEC 

0040H 

0120H 

PUB 

DEFAULT_HANDLER 

0040H 

0144H 

PUB 

READYLISTROOT 

0040H 

0148H 

PUB 

INTERRORENTRY 

0040H 

014CH 

PUB 

SYSTEMEXCEPTIONH 

-ANDLERPTR 

0040H 

0150H 

PUB 

DELETIONTASKTOKE 

-N 

0040H 

0152H 

PUB 

EXTENSIONLISTROO 

-T 

0040H 

0154H 

PUB 

DELETION OBJECT 
-BASE 

0040H 

0156H 

PUB 

SYSTEMPOOLTOKEN 

0040H 

0158H 

PUB 

ROOTUOBTOKEN 

0040H 

015AH 

PUB 

MINTRANSSIZE 

0040H 

015CH 

PUB 

LAST_NDP_TASK 

0040H 

015EH 

PUB 

NDP_INTERRUPT LE 
-VEL_VAR 

0040H 

0160H 

PUB 

PARAM_VALIDATION 

-_VECTOR 

0040H 

0162H 

PUB 

REGION_FLAOS 

0040H 

0164H 

PUB 

TASK_WA I T I NG_FLA 
-GS 

0040H 

0166H 

PUB 

REGION_TOKEN_TAB 

-LE 

0040H 

0176H 

PUB 

SIGNAL_Q_INDEX 

0040H 

0178H 

PUB 

SIGNAL_Q 

0040H 

01E8H 

PUB 

KERNEL_FLAG 

0040H 

01E9H 

PUB 

ACTIVATE_SIONAL_ 

0040H 

OlEAH 

PUB 

FILLCHAR 

0040H 

OlEBH 

PUB 

NUM SLAVES 

0040H 

OlECH 

PUB 

OLD SLAVE NUM 

0040H 

OlEDH 

PUB 

INTMASK 

0040H 

01F6H 

PUB 

DISABLEMASK 

0040H 

OlFFH 

PUB 

LEVEL SET TABLE 

0040H 

0208H 

PUB 

I MR PORT 

0040H 

021 AH 

PUB 

EOI PORT 

0040H 

022CH 

PUB 

ISR_PORT 

0040H 

023EH 

PUB 

PIC_INFO 

0040H 

0247H 

PUB 

CLOCK_SPEC_EOI 

0040H 

0248H 

PUB 

CLOCK ON 

0040H 

0249H 

PUB 

CLOCK_OFF 

0040H 

024AH 

PUB 

CLOCK LEVEL 

0040H 

05D0H 

PUB 

END_OF_DATA 

F800H 

45CCH 

PUB 

NDP_INTERRUPT LE 
-VEL 

F800H 

45C2H 

PUB 

VALIDATE_PARAMS 
-BODY DUMMY 

FSOOH 

4542H 

PUB 

OETDESCRTOKEN 

F800H 

4556H 

PUB 

GETDESCRPO INTER 

F800H 

4567H 

PUB 

GETPO INTER 

FSOOH 

4S3DH 

PUB 

SCANMEMORY 

F800H 

4538H 

PUB 

OVERFLOW 

FBOOH 

4533H 

PUB 

NENTRY_BODY 

FSOOH 

452EH 

PUB 

KSUSPEND 

F800H 

4529H 

PUB 

KINITIALIZE 

F800H 

4524H 

PUB 

KENABLELEVELNS 

FSOOH 

451FH 

PUB 

KENABLELEVEL 

F800H 

451AH 

PUB 

KCREATEREeiONNS 

F800H 

4515H 

PUB 

KCREATEOBJECTNS 

FSOOH 

451 OH 

PUB 

KCREATEOBJECT 

F800H 

450BH 

PUB 

INITNDP 

F800H 

4506H 

PUB 

INITIALIZE 

FSOOH 

4501H 

PUB 

FINISHINITIALIZA 

-TION 

F800H 

44FCH 

PUB 

EOI ROUTINE 

F800H 

44F7H 

PUB 

DIVIDEBYZERO 

FSOOH 

44F2H 

PUB 

DECODE_LEVEL 

F800H 

44EDH 

PUB 

COMMON_ERROR 

F800H 

44E8H 

PUB 

CLOCKENTRY_BODY 

FSOOH 

44E3H 

PUB 

ARRAYBOUNOS 

F800H 

44D0H 

PUB 

SYSTEMEXCEPT I ONH 
-ANDLER 

FSOOH 

4472H 

PUB 

INITIALIZE_TIMER 

FSOOH 

43AEH 

PUB 

INITIALIZE_PICS 

F800H 

435CH 

PUB 

INIT INTERNAL RE 
-6I0NS 

F800H 

434EH 

PUB 

NDP_INTERRUPT_HA 

-NDLER 

FSOOH 

433FH 

PUB 

CLOCKENTRY 

F800H 

4336H 

PUB 

NENTRY 

FSOOH 

40FEH 

PUB 

INITIALIZENUCLEU 

-S 

FSOOH 

40B6H 

PUB 

RQWAITINTERRUPT 

-BODY 

F800H 

40B1H 

PUB 

RQSIONALINTERRUP 

-T_BODY 

FSOOH 

40ACH 

PUB 

RQGETLEVEL_BODY 

FSOOH 

40A7H 

PUB 

RQEXITINTERRUPT_ 

-BODY 

F800H 

40A2H 

PUB 

R(JENTER INTERRUPT 
-„BODY 

F800H 

409DH 

PUB 

RQDISABLE_BODY 

FSOOH 

4094H 

PUB 

RQWAITINTERRUPT 

F800H 

408AH 

PUB 

RQSIONALINTERRUP 

F800H 

4080H 

PUB 

RQGETLEVEL 

FSOOH 

4076H 

PUB 

RQENTER INTERRUPT 

F800H 

406CH 

PUB 

RQEXITINTERRUPT 

FBOOH 

4062H 

PUB 

RQDISABLE 

FSOOH 

40 SDH 

PUB 

NUNLOCK_DELETION 
- OBJECT 

F800H 

4058H 

PUB 

NUNLOCKNS 

FSOOH 

4053H 

PUB 

NUNLOCK 

FSOOH 

404EH 

PUB 

NOPEN_DELETION 0 
-BJECT 

F800H 

4049H 

PUB 

NOPENNS 

FSOOH 

4044H 

PUB 

NOPEN 

FSOOH 

403FH 

PUB 

NLOCK_DELET I ON_0 
-BJECT 

F800H 

403AH 

PUB 

NLOCKNS 

FSOOH 

4035H 

PUS 

NLOCK 

FSOOH 

4030H 

PUB 

NCLOSE_DELETION_ 

-OBJECT 

F800H 

402BH 

PUB 

NCLQSENS 

FSOOH 

4026H 

PUB 

NCLOSE 

FSOOH 

4021H 

PUB 

DELETERUNNINGTAS 

F800H 

401CH 

PUB 

DELETEOBJECT 

FSOOH 

400AH 

PUB 

COPYRIGHT 

FSOOH 

4000H 

PUB 

NBEGIN 

F800H 

4000H 

PUB 

I N I T_NUC LEUS_JUM 

FC5DH 

0004H 

PUB 

IMR_START 

FC5CH 

OOOEH 

PUB 


FC5CH 

OOOFH 

PUB 

INIT_CMD1 

FC5CH 

OOlOH 

PUB 

INIT_CMD5_MASTER 

FC5CH 

001 IH 

PUB 


FC5CH 

0012H 

PUB 

I N I T_CMD4_MASTER 

FC61H 

OOOEH 

PUB 

SLAVE_TABLE 

FC61H 

0003H 

PUB 


FC61H 

0005H 

PUB 

CL0CK_0_P0RT 

FC61H 

0007H 

PUB 

CLOCK COUNT 

FC61H 

OOOAH 

PUB 


FC61H 

F800H 

OOOBH 

4576H 

PUB 

PUB 

C^CLOCK SPEC_EOI 
LEVEL7 HANDLER 

FC61H 

FBOOH 

OOOCH 

4S74H 

PUB 

PUB 

. C_CLOCK_ON 
PARAM_VALIDATION 
-„PATH~ 

FC61H 

0009H 

PUB 



MEMORY MAP OF MODULE MINIMAL 80130 
READ FROM FILE ; FI ; SUP 130. LNK 
WRITTEN TO FILE :F1:SUP130 


SEGMENT MAP 


START STOP 


LENGTH ALIGN NAME 


CLASS 


OOOOOH 003FFH 
00400H 009EFH 
009FOH 009FFH 
OOAOOH OOAOFH 
OOAIOH OOAIFH 
OOA20H 00A2FH 
00A30H 00A3FH 
00A40H 00A4FH 
00A50H 00A5FH 


0400H A 
05F0H W 
OOlOH G 
OOlOH G 
OOlOH G 
OOlOH G 
OOlOH G 
OOlOH G 
OOlOH G 


(ABSOLUTE) 

DATA 

INTVEC_REO_SEG 

EXT_REG_SEG 

job_reg_seg 

SEM_REG_SEG 
MAIL REG_SEG 
OD_REG SEG 
POOL REG SEG 


DATA 

DATA 

DATA 

DATA 

DATA 

DATA 

DATA 

DATA 
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00A60H 

G0A6FH 

OOIOH 

G 

deletion REG_S 
-EG 

DATA 

O0A7OH 

OOA70H 

OOOOH 

Ul 

STACK 

STACK 

00A70H 

00A70H 

OOOOH 

G 

??SEG 


F8000H 

FC5CDH 

45CEH 

N 

CODE 

CODE 

FC5CEH 

FC5D2H 

0005H 

U 

PIC CNF SEO 

CODE 

F95D4H 

FC5E5H 

0012H 

Ul 

IMR PORT 

CODE 

FC5E6H 

FC5F7H 

0012H 

N 

_EOI,PORT 

CODE 

FC5FSH 

FC609H 

0012H 

Ul 

"'iSR^READ PORT 

CODE 

FC60AH 

FC612H 

0009H 

B 

pic" info"" 

CODE 

FC613H 

FC61CH 

OOOAH 

B 

TIMER CNF SEG 

CODE 

FC6J.EH 

FC61EH 

OQDOH 

Ul 

CSEG 

CODE 

[FC61EH 

FC61FH 

0002H 

Ul 

SLAVE_5EG 

CODE [ 

FC6SOH 

FC6S0H 

OOOOH 

U 

MEMORY 

MEMOR> 


GROUP MAP 

ADDRESS GROUP OR SEGMENT NAME 
00400H DGROUP 
DATA 

INTVEC_REG_SEG 
EXT_REG_SEG 
JOD„REG„SEG 
SEM„REG_SEG 
MAIL REG S?G 
□D REG^SEG 
PODL^REG^SEG 
DELETION_REG_SEG 
F8000H CGRPUP 
CODE 

PIC_CNF_SEG 
IMR PORT 
EOI PORT 

IisrZread.port 

PIC INFO 
TIMER_CNF^SEG 
CSEG 


SLAVE_,£5EG 


D-3 


LAST RAM PYTE USED 


LAST EPROM BYTS USED 
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APPENDIX E 

APPLICATION JOB LOCATE MAP 


E-1 


AFN-02058A 




AP-130 


ISIS-ri MCS-86 LOCATER. VI. 2 INVOKED BY; 

L0C86 : FI ; AP130. LNK TO :F1;API30 

ORDER (CLASSES(DATA, STACK, MEMORY) ) 

SEGSIZE (STACK (0)) 

ADDRESSES (CLASSES (DATA (00A7OH), 

CODE (0FC620H))) ?< 

MAP PRINT (; FI: AP130. MP2) 


OBOECTCONTROLS (NOLINES, NOCOMMENTS, NOPUBLICS, NOSYMBOLS) 
WARNING 26: DECREASING SIZE OF SEGMENT 

SEGMENT: STACK 


SYMBOL TABLE OF MODULE DEMO 130 
READ FROM FILE ; FI : AP 130. LNK 
WRITTEN TO FILE :F1;AP130 


BASE 

OFFSET 

TYPE 

SYMBOL 

BASE 

OFFSET 

TYPE. 

SYMBOL. 

FC62H 

0B3AH 

PUB 

RQENDINITTASK 

FC62H 

OBICH 

PUB 

RO_N.„c, re:turm„40 

FC62H 

OBOOH 

PUB 

RQ_N„C_RETURN.„20 

FC62H 

0AE4H 

PUB 

RO„N^.C RETURN_.14 

FC62H 

0AC8H 

PUB 

RQ_N C RETURN 12 

FC62H 

OAACH 

PUB 

RqIn"c™return_.io 

FC62H 

0A90H 

PUB 

RqIn C RETURN 8 

FC62H 

0A74H 

PUB 

RqIn_cIreturm_6 

FC62H 

0A58H 

PUB 

RQ N C RETURn’“4 

FC62H 

0A3EH 

PUB 

rqerror 

FC62H 

0A28H 

PUB 

RQGETLEVEL 

FC62H 

OAOEH 

PUB 

RQSIGNALEXCEPTIO 

-N 

RQSIGNALINTERRUP 

FC62H 

09F0H 

PUB 

RQWAITINTERRUPT 

FC62H 

09DAH 

PUB 

FC62H 

09D4H 

PUD 

RQDELETESEMAPHOR 

FC62H 

09CEH 

PUB 

R(3DELETEMAILB0X 

FC62H 

09B8H 

PUB 

RQEXITINTERRUPT 

FC62H 

09B2H 

PUB 

RQUNCATALOGOBJEC 

FC62H 

09ACH 

PUB 

RQSENDUNITS 

FC62H 

09A6H 

PUB 

rqsuspendtask 

FC62H 

09A0H 

PUB 

RQSETPRIORITY 

FC62H 

099AH 

PUB 

RQSETPOOLMIN 

FC62H 

0994H 

PUB 

RQSETOSEXTENSION 

FC62H 

098EH 

PUB 

rqsendmessage 

FC62H 

0988H 

PUB 

RGSLEEP 

FC62H 

0982H 

PUB 

RQSETINTERRUPT 

FC62H 

097CH 

PUB 

rqsetexceptionha 

-NDLER 

FC62H 

0976H 

PUB 

RQSENDCDNTROL 

FC62H 

0970H 

PUB 

R(JRECEIVEUNITS 

FC62H 

096AH 

PUB 

RQRESUMETASK 

FC62H 

0938H 

PUB 

R(3RECEIVEMESSAGE 

FC62H 

0932H 

PUB 

RQRESETINTERRUPT 

FC62H 

092CH 

PUB 

R(3RECEIVEC0NTR0L 

FC62H 

0926H 

PUB 

RQOFFBPRING 

FC62H 

0920H 

PUB 

R(3LOOKUPOBJECT 

FC62H 

091 AH 

PUB 

RQINSPECTCOMPOSI 

-TE 

RQGETTYPE 

FC62H 

0914H 

PUB 

RQGETTASKTOKENS 

FC62H 

090EH 

PUB 

FC62H 

0908H 

PUB 

RQGETSIZE 

FC62H 

0902H 

PUB 

RQGETPRIORITY 

FC62H 

08FCH 

PUB 

rqgetpoolattrib 

FC62H 

08F6H 

PUB 

. RQGETEXCEPTIONHA 
-NDLER 

FC62H 

08F0H 

PUB 

rqforcedelete 

FC62H 

08EAH 

PUB 

RQENABLE 

FC62H 

0SD4H 

PUB 

RQENTER INTERRUPT 

FC62H 

OBCEH 

PUB 

RQENABLEDELETION 

FC62H 

08C8H 

PUB 

R(3DELETETASK 

FC62H 

08C2H 

PUB 

rqdeletesegment 

FC62H 

08ACH 

PUB 

RQDI SABLE 

FC62H 

08A6H 

PUB 

RQDELETEREGION 

FC62H 

08A0H 

PUB 

RQDELETEUOB 

FC62H 

089AH 

PUB 

RQDELETEEXTENSIO 

-M 

RQDELETECOMPOSIT 

FC62H 

0894H 

PUB 

R(3DISABLEDELETI0 

-N 

RQCREATETASK 

FC62H 

088EH 

PUB 

FC62H 

0888H 

PUB 

FC62H 

0882H 

PUB 

RQCREATESEMAPHOR 

FC62H 

087CH 

PUB 

RQCREATESEGMENT 

FC62H 

0876H 

PUB 

RQCREATEREGION 

FC62H 

0870H 

PUB 

R(3CATALOGOBJECT 

FC62H 

086AH 

PUB 

RQCREATEMAILBOX 

FC62H 

0864H 

PUB 

RQCREATEJOB 

FC62H 

085EH 

PUB 

RQCREATEEXTENSIO 

-N 

RQALTERCOMPOSITE 

FC62H 

0858H 

PUB 

RQCREATECOMPOSIT 

FC62H 

0852H 

PUB 

FC62H 

084CH 

PUB 

RQACCEPTCONTROL 

FC6SH 

06B5H 

PUB 

INI TTASK 

DEMO 130: SYMBOLS 

AND LINES 





FD17H 

OOOCH 

SYM 

MEMORY 

FC62H 

OOOOH 

SYM 

ASCIICODE 

00A7H 

OOOOH 

SYM 

DATASEGPTR 

00A7H 

OOOOH 

SYM 

DATASEGADDR 

00A7H 

0004H 

SYM 

HARDWARE IN I TTASK 
-TOKEN 

00A7H 

0006H 

SYM 

STATUSTASKTOKEN 

00A7H 

0008H 

SYM 

motortasktoken 

00A7H 

OOOAH 

SYM 

TIMETASKTOKEN 

00A7H 

OOOCH 

SYM 

AC HANDLER TOKEN 

00A7H 

OOOEH 

SYM 

CRTOUTTASKTOKEN 

00A7H 

001 OH 

SYM 

COMMANDTASKTOKEN 

00A7H 

0012H 

SYM 

inittasktoken 

00A7H 

0014H 

SYM 

CRTMAILBOXTOKEN 

00A7H 

0016H 

SYM 

CRTREGIONTOKEN 

FC62H 

0084H 

SYM 

COUT 

STACK 

0004H 

SYM 

CHAR 

FC62H 

OOAIH 

SYM 

CIN 

FC62H 

00B9H 

SYM 

HARDWAREINITTASK 

OOA7H 

0018H 

SYM 

hardinitexceptco 

-DE 

par AM51 INDEX 

FC63H 

001 OH 

SYM 

PARAM51 

00A7H 

0040H 

SYM 

FC62H 

0016H 

SYM 

SIGNONMESSAGE 

00A7H 

004 IH 

SYM 

SIGNONINDEX 

FC62H 

013BH 

SYM 

STATUSTASK 

00A7H 

0042H 

SYM 

STATUSCOUNTER 

00A7H 

001 AH 

SYM 

STATUSEXCEPTCODE 

00A7H 

0043H 

SYM 

cwstepdelay 

00A7H 

0044H 

SYM 

CCWSTEPDELAY 

00A7H 

004 5H 

SYM 

CWPAUSEDELAY 

00A7H 

0046H 

SYM 

CCWPAUSEDELAY 

FC62H 

0172H 

SYM 

MOTORTASK 

00A7H 

OOlCH 

SYM 

MOTOREXCEPTCODE 

00A7H 

0047H 

SYM 

MOTORPOSITION 

0OA7H 

0048H 

SYM 

MOTORPHASE 

FC62H 

0039H 

SYM 

PHASECODE 

00A7H 

0049H 

SYM 

ACCYCLECOUNT 

FC62H 

0256H 

SYM 

AC HANDLER 

00A7H 

001 EH 

SYM 

ACEXCEPTCODE 

FC62H 

029CH 

SYM 

PROTECTEDCRTOUT 

STACK 

0006H 

SYM 

CHAR 

STACK 

0002H 

SYM 

CRTEXCEPTCODE 

00A7H 

004AH 

SYM 

SECONDCOUNT 

00A7H 

004BH 

SYM 

MINUTECOUNT 

00A7H 

004CH 

SYM 

HOURCOUNT 

FC62H 

02CFH 

SYM 

TIMET ASK 

00A7H 

0020H 

SYM 

timeexceptcode 

FC62H 

038BH 

SYM 

PRINTTOD 

00A7H 

0022H 

SYM 

TPDMESSAGETOKEN 

00A7H 

0024H 

SYM 

TODEXCEPTCODE 

00A7H 

0026H 

SYM 

TODSEGMENTOFFSET 

00A7H 

0028H 

SYM 

TODSEGMENTBASE 

00A7H 

0026H 

SYM 

TODSEGMENTPNTR 

FC62H 

003DH 

SYM 

TODTEMPLATE 

00A7H 

0026H 

BAS 

TODSTRING 

00A7H 

004DH 

SYM 

TODSTRINGINDEX 

FC62H 

0489H 

SYM 

PRIMTSTATUS 

00A7H 

002AH 

SYM 

STATUSMESSAGETOK 

00A7H 

002CH 

SYM 

STATUSEXCEPTCODE 


-EN 


Et2 
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OOA7H 002EH SYM 

00A7H 002EH SYM 

00A7H 002EH BAS 

00A7H 004FH SYM 

00A7H 0050H SYM 

00A7H 0034H SYM 

00A7H 0038H SYM 

00A7H 0038H SYM 

FC62H 05AFH SYM 


STATUSSEOMENTOFF 

-SET 

STATUSSEGMENTP NT 
-R 

STATUSSTRING 

BITPATTERN 

MESSAGELENGTH 

RESPONSETOKEN 

MESSAGESEGMENTOF 

-FSET 

MESSAGESEGMENTPN 

-TR 

COMMANDTASK 


00A7H 0030H SYM 

FC62H 00S9H SYM 

00A7H 004EH SYM 

FC62H 0S2FH SYM 
00A7H 0032H SYM 

00A7H 0036H SYM 

OOA7H 003AH SYM 

OOA7H 0038H BAS 

00A7H 005 IH SYM 


STATUSSEGMENTBAS 

-E 

STATUSTEMPLATE 

STATUSSTR I NO I NDE 
-X 

CRTOUTTASK 

MESSAGETOKEN 

MESSAGEEXCEPTCOD 

-E 

MESSAGESEGMENTBA 

-SE 

MESSAGESTR INGCHA 
-R 

CONSOLECHAR 


00A7H 003CH SYM COMMANDEXCEPTCOD |fC62H 06B5H SYM INITTASK W INITIALIZATION TASK STARTING ADDRESS 

-E ' ' 


00A7H 

003EH 

SYM 

INITEXCEPTCODE 

FC62H 

0084H 

LIN 

302 

FC62H 

0087H 

LIN 

304 

FC62H 

0093H 

LIN 

305 

FC62H 

O096H 

LIN 

306 

FC62H 

009DH 

LIN 

307 

FC62H 

OOAIH 

LIN 

308 

FC62H 

00A4H 

LIN 

309 

FC62H 

OOBOH 

LIN 

310 

FC62H 

00B3H 

LIN 

311 

FC62H 

00B9H 

LIN 

312 

FC62H 

00B9H 

LIN 

313 

FC62H 

OOBCH 

LIN 

319 

FC62H 

00C2H 

LIN 

320 

FC62H 

OOC8H 

LIN 

321 

FC62H 

OOCEH 

LIN 

322 

FC62H 

OODIH 

LIN 

323 

FC62H 

00E4H 

LIN 

324 

FC62H 

OOEFH 

LIN 

325 

FC62H 

00F8H 

LIN 

326 

FC62H 

OlOCH 

LIN 

327 

FC62H 

0116H 

LIN 

328 

FC62H 

OllFH 

LIN 

329 

FC62H 

012CH 

LIN 

330 

FC62H 

0139H 

LIN 

331 

FC62H 

013BH 

LIN 

332 

FC62H 

013EH 

LIN 

335 

FC62H 

0143H 

LIN 

336 

FC62H 

0150H 

LIN 

337 

FC62H 

0150H 

LIN 

338 

FC62H 

015CH 

LIN 

339 

FC62H 

0160H 

LIN 

340 

FC62H 

016DH 

LIN 

341 

FC62H 

0170H 

LIN 

342 

FC62H 

0172H 

LIN 

344 

FC62H 

0175H 

LIN 

348 

FC62H 

017AH 

LIN 

349 

FC62H 

017FH 

LIN 

350 

FC62H 

0184H 

LIN 

351 

FC62H 

0189H 

LIN 

352 

FC62H 

0196H 

LIN 

353 

FC62H 

0196H 

LIN 

354 

FC62H 

01 ASH 

LIN 

355 

FC62H 

OIBOH 

LIN 

356 

FC62H 

OIBDH 

LIN 

357 

FC62H 

OICDH 

LIN 

358 

FC62H 

01D6H 

LIN 

359 

FC62H 

01E6H 

LIN 

360 

FC62H 

01F5H 

LIN 

361 

FC62H 

0202H 

LIN 

362 

FC62H 

020FH 

LIN 

363 

FC62H 

021FH 

LIN 

364 

FC62H 

0228H 

LIN 

365 

FC62H 

0238H 

LIN 

366 

FC62H 

023BH 

LIN 

367 

FC62H 

0256H 

LIN 

369 

FC62H 

0259H 

LIN 

371 

FC62H 

0266H 

LIN 

372 

FC62H 

0270H 

LIN 

373 

FC62H 

0278H 

LIN 

375 

FC62H 

027DH 

LIN 

376 

FC62H 

028AH 

LIN 

377 

FC62H 

028DM 

LIN 

378 

FC62H 

029AH 

LIN 

379 

FC62H 

029CH 

LIN 

380 

FC62H 

02A0H 

LIN 

383 

FC62H 

02ACH 

LIN 

384 

FC62H 

02B8H 

LIN 

385 

FC62H 

02BBH 

LIN 

386 

FC62H 

02C2H 

LIN 

387 

FC62H 

02CAH 

LIN 

388 

FC62H 

02CFH 

LIN 

390 

FC62H 

02D2H 

LIN 

392 

FC62H 

02D7H 

LIN 

393 

FC62H 

02F3H 

LIN 

394 

FC62H 

0300H 

LIN 

395 

FC62H 

030FH 

LIN 

396 

FC62H 

031EH 

LIN 

397 

FC62H 

032DH 

LIN 

398 

FC62H 

033AH 

LIN 

399 

FC62H 

034EH 

LIN 

400 

FC62H 

0354H 

LIN 

401 

FC62H 

035DH 

LIN 

402 

FC62H 

0366H 

LIN 

403 

FC62H 

036FH 

LIN 

404 

FC62H 

037CH 

LIN 

405 

FC62H 

0389H 

LIN 

406 

FC62H 

03SBH 

LIN 

407 

FC62H 

038EH 

LIN 

415 

FC62H 

039FH 

LIN 

416 

FC62H 

03A7H 

LIN 

417 

FC62H 

03ADH 

LIN 

418 

FC62H 

03BEH 

LIN 

419 

FC62H 

03D0H 

LIN 

420 

FC62H 

03D9H 

LIN 

421 

FC62H 

03FSH 

LIN 

422 

FC62H 

040EH 

LIN 

423 

FC62H 

0427H 

LIN 

424 

FC62H 

0440H 

LIN 

425 

FC62H 

0459H 

LIN 

426 

FC62H 

0472H 

LIN 

427 

FC62H 

0487H 

LIN 

428 

FC62H 

0489H 

LIN 

429 

FC62H 

0489H 

LIN 

430 

FC62H 

048CH 

LIN 

439 

FC62H 

049DH 

LIN 

440 

FC62H 

04A5H 

LIN 

441 

FC62H 

04ABH 

LIN 

442 

FC62H 

04BCH 

LIN 

443 

FC62H 

04CEH 

LIN 

444 

FC62H 

04D7H 

LIN 

445 

FC62H 

04DFH 

LIN 

446 

FC62H 

04EEH 

LIN 

447 

FC62H 

050BH 

LIN 

448 

FC62H 

050FH 

LIN 

449 

FC62H 

0518H 

LIN 

450 

FC62H 

052DH 

LIN 

451 

FC62H 

052FH 

LIN 

452 

FC62H 

0532H 

LIN 

460 

FC62H 

053FH 

LIN 

461 

FC62H 

053FH 

LIN 

462 

FC62H 

055AH 

LIN 

463 

FC62H 

0560H 

LIN 

464 

FC62H 

0568H 

LIN 

465 

FC62H 

0573H 

LIN 

466 

FC62H 

0588H 

LIN 

467 

FC62H 

0592H 

LIN 

468 

FC62H 

O590H 

LIN 

469 

FC62H 

05AAH 

LIN 

470 

FC62H 

05ADH 

LIN 

471 

FC62H 

05AFH 

LIN 

472 

FC62H 

05B2H 

LIN 

475 

FC62H 

05BFH 

LIN 

476 

FC62H 

05BFH 

LIN 

477 

FC62H 

05C9H 

LIN 

478 

FC62H 

05D0H 

LIN 

479 

FC62H 

05DAH 

LIN 

480 

FC62H 

05E0H 

LIN 

481 

FC62H 

05F4H 

LIN 

483 

FC62H 

05FAH 

LIN 

4S4 

FC62H 

0600H 

LIN 

485 

FC62H 

061 OH 

LIN 

486 

FC62H 

0616H 

LIN 

487 

FC62H 

061CH 

LlN 

488 

FC62H 

062CH 

LIN 

489 

FC62H 

063CH 

LIN 

490 

FC62H 

064CH 

LIN 

491 

FC62H 

065CH 

LIN 

492 

FC62H 

066CH 

LIN 

493 

FC62H 

067CH 

LIN 

494 

FC62H 

068CH 

LIN 

495 

FC62H 

069CH 

LIN 

496 

FC62H 

06B0H 

LIN 

498 

FC62H 

06B3H 

LIN 

4 < 5>9 

FC62H 

06B5H 

LIN 

500 

FC62H 

06B8H 

LIN 

502 
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FC62H 

06C4H LIN 

503 


FC62H 

06D5H LIN 

504 

FC62H 

06E6H LIN 

505 


FC62H 

06F6H LIN 

506 

FC62H 

071FH LIN 

507 


FC62H 

072CH LIN 

508 

FC62H 

0755H LIN 

509 


FC62H 

0762H LIN 

510 

FC62H 

078BH LIN 

511 


FC62H 

0798H LIN 

512 

FC62H 

07C1H LIN 

513 


FC62H 

07CEH LIN 

514 

FC62H 

07F7H LIN 

515 


FC62H 

0804H LIN 

516 

FC62H 

082DH LIN 

517 


FC62H 

083AH LIN 

518 

FC62H 

083DH LIN 

519 


FC62H 

084AH LIN 

520 

FC62H 

0084H LIN 

521 





MEMORY 

MAP OF MODULE DEMO 130 





READ FROM FILE ; FI 

; API 30. LNK 





WRITTE^ 

1 TO FILE : FI: AP130 





SEGMENT 

■ MAP 






START 

STOP 

LENGTH ALIGN 

NAME 


CLASS 


( 00A70H 

OOACIH 

0052H W 

DATA 


DATA 

LAST DATA BYTE OF APPLICATION JOB 

00AC2H 

00AC2H 

OOOOH W 

STACK 


STACK 


OOADOH 

OOADOH 

OOOOH G 

??SEG 




I FC620H 

FD17BH 

0B5CH W 

CODE 


CODE 

LAST CODE BYTE OF APPLICATION JOB 

FD17CH 

FD17CH 

OOOOH W 

MEMORY 


MEMORY 


GROUP MAP 






ADDRESS GROUP OR 

SEGMENT NAME 





FC620H 

CGROUP 







CODE 






00A70H 

DGROUP 







DATA 
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APPENDIX F 
ROOT JOB LOCATE MAP 


F-1 


AFN-02058A 




AP^30 


LOCATfiW, Vi. a INVOKiei) by: 

LO<i86 ; f 1! RJB130. Ink tt 

to iFllRJBlOO it 

MAP RRtNf < : f ii |t(JlSH30. mpa) «t 

□d(nPli> htipl. ndCMi nosb) & 

PC(noli» pi, nbtrti, nosb) «« 
Se03l!ZF:(statl((O} ) k 

OF^O&R t c lasses i datai stack, mediory)) it 
At)OR£3S£S ( C 1 a s s b b ( c ti d e ( OFB 1 OOH ) , & 

data(OOAOOH) n 

WAR^flNG 26: bSdREAStbiG SIZE OP SEGMENT 

SEGMENT: STACK 


symbol table OF MODULE ROOT 
READ FROH FtLB ; Fl ; R JDlSOi LNK 
wRtTTkN TO FILE :Fl;RJSl30 


BASE 

OFFSET 

TYPE 

syMbOl 

BASE 

OFFSET 

Type 

symbol 

FD18H 

Disoh 

PUB 

NUC^lNlT^ENTRY 

FD18H 

0184H 

PUB 

COdEdaTa 

|fDi8h 

OOllH 

PUB 

RQSTARTADDRESSj^ 

ROOT JOB STARTIN6 ADDRESS PD i SH 

FD18M 

OOOOH 

Pub 

CRASH 

FblSH 

002AH 

puB 

RGROOTUOBUERSION 

FD18H 

0030H 

PUB 

ROOTTASK 

FDISH 

OlOtH 

PUB 

SYSTEMSuiciDE 

FD18H 

GUSH 

PUB 

RqCREATEjOB 

fdiSh 

OllEH 

PUB 

RGGETTASKtOKENS 

FDIBH 

oiSah 

PUB 

RQSUSPENDTASK 

FD18H 

012AH 

PUB 

PO_N^CJ5lETURN_6 

FD i8h 

0146H 

PUB 

R0_N^C^RETURN^40 

FD18H 

0162H 

PuB 

RQERROR 

ooadh 

oooOh 

PUB 

jobnumbEr 

OOADH 

0002H 

PUB 

ROOTTASKSTATUS 


MEMORY HAF of module ROOT 
read from pile ;Fi:RJSl30. Lnk 
WRITTEN TO FILE ;F1:RJB130 


001 Oh pub 


INTERROR 


MODULE START ADDRESS PARAGRAPH ^ PDlSM OFFSET * OOllH 
Segment Map 


START STOP length ALIGM NAME CLASS 


OOADOH 

OOADOH 

0004H 

w 

Data 

data 

|OOaD4h 

OOBFFH 

OiOCH 

w 

INIT^STACK 

stack 

00c OOH 

OOCOOH 

OOoOH 

w 

stack 

STACK 

OOCOOH 

OOCOOH 

OOOOH 

G 

T?SE0 


FDISOH 

FD33PM 

01 BAH 

w 

CODE 

CODE 

FD33AH 

FDS4SH 

OOOCH 

w 

SAB ^DESCRIPTOR 
*-s 

CODE 

FD346H 

FD366H 

002 IH 

w 

U^J^DESCRIPTOR 

“S 

CODE ^ 


LASt DATA BYTE OF BOOT JOB 


LAST CODE BYT6 OF ROOT JOB 


FD368M FD368H OOOOH W MEMORY MEMORY 


GROUP MAP 

ADDRESS GROUP OR SEGMENT NAME 
OOADOH DGROUP 
DATA 

FDiSOH CGROUP 
CODE 

Sab ^DESCRIPTORS 
U^JJDESCRIPTORS 


F-2 


AFN-02058A 
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